How accessible is this app?

[rugk]

In StreetComplete there are many quests about accessibility (wheelchair, blind people), but how accessible is the app actually?

I don't know much about it so I am just linking to the Android site, but I assume screen readers and such things are possible. There are common concepts for the web, whcih I'll just assume here too.

The most obvious example I see are the quest icons: Do they have an alternative text describing the image? If not, then I can provide them, because I actually already write them for the wiki.

[westnordost]

They can't have an alternative text because they are part of the map view. The map view is a black box, in that matter. So, don't bother. A version of this app for blind people does not make sense, because you need eyes to do a survey.

[rugk]

I am very sure blind people are very likely to not like that statement that the app does not make sense for them. Sure, maybe they cannot answer some quests, but others, especially the ones that affect themselves, can maybe answered better by them than by anyone else. Of course, I am talking about the tactile quests here…

Also accessibility is not only about blind people. Quoting Android docs:

Common disabilities that affect a person's use of an Android device include blindness or low vision, color blindness, deafness or impaired hearing, and restricted motor skills. When you develop apps with accessibility in mind, you make the user experience better not only for users with these disabilities, but also for all of your other users.

But to keep the discussion short: My main idea was the alternative text, you said it is not possible, so I also see no reason to keep it open anymore, unless someone else finds a problem with the app in this way. 😃

[chrisdebian]

rugk, I don't know how this would be technically implemented, but I strongly support your thought. For example, W3C standards say that web pages should have alternative text to pictures, which can be read by screen readers. With a small number of people activily coding for StreetComplete, I know that these extra bits of functionality may not seem to be a priority; but I worry that excluding groups of visually impaired people (for example), isn't a great thing to do. I know that not replying to your suggestion, would make me guilty of being part of this discrimination, even though I don't know how to fix the problem. Essentially, it would be great to have this functionality on the 'to do' list. Thanks, Chris chris_debian 2E0FRU

…

On Sun, 20 Aug 2017, 21:02 rugk ***@***.***> wrote: I am very sure blind people are very likely to not like that statement that the app does not make sense for them. Sure, maybe they cannot answer some quests, but others, especially the ones that affect themselves, can maybe answered better by them than by anyone else. Of course, I am talking about the tactile quests here… Also accessibility is not only about blind people. Quoting Android docs: Common disabilities that affect a person's use of an Android device include blindness or low vision, color blindness, deafness or impaired hearing, and restricted motor skills. When you develop apps with accessibility in mind, you make the user experience better not only for users with these disabilities, but also for all of your other users. But to keep the discussion short: My main idea was the alternative text, you said it is not possible, so I also see no reason to keep it open anymore, unless someone else finds a problem with the app in this way. 😃 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#520 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARGrd7qbDRiMkQj64YHwWRMRdPveBb6zks5saJDCgaJpZM4O8s80> .

[rugk]

I completely agree, but I also agree with the technical reasons @westnordost provided, explaining why alt-texts are not possible currently. I would love to see a PR here, but even better than a PR would be users, which are actually affected by this and which can tell how they (can) move the app and what needs to be improved. Because we can only tackle this problem as "outsiders", so some feedback there would be nice.
Without that doing any TODO items gets difficult.

---

However, to get back to some actual actions here. As I explained above, I understand this issue cannot be solved yet, so I opened an issue on tangram – the map render used – about that feature: tangrams/tangram-es#1627

[chrisdebian]

Agreed :-)

…

On Sun, 20 Aug 2017, 21:27 rugk ***@***.***> wrote: I completely agree, but I also agree with the *technical* reasons @westnordost <https://github.com/westnordost> provided, explaining why alt-texts are not possible currently. I would love to see a PR here, but even better than a PR would be users, which are actually affected by this and which can tell how they (can) move the app and what needs to be improved. Because we can only tackle this problem as "outsiders", so some feedback there would be nice. Without that doing any TODO items gets more difficult. ------------------------------ However, to get back to some actual actions here. As I explained above, I understand this issue cannot be solved yet, so I opened an issue on tangram – the map render used – about that feature: tangrams/tangram-es#1627 <tangrams/tangram-es#1627> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#520 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARGrd3mbXoyKMVrleymnTkd49Prd6EHUks5saJa9gaJpZM4O8s80> .

[rugk]

By the iOS codebase migration (see #5616 and #5421), BTW; maybe the app could or will automatically get more accessible BTW. At least Kotline Multiplatorm has a page for that, already and I know iOS devices are quite popular for blind or visually impaired people. Well… let's see. (Just came upon this idea because another Protoype fund project currently offers free a10y reviews).

[mnalis]

I agree that accessibility is important (e.g. I've written few conversion apps for the routing apps for blind people; tried to make my cycling events website semantic and accessible; and just a month ago I've come back from volunteering in Digital audio production camp for blind people in Zadar. So I care about the issue); but I don't think that StreetComplete is good target app for blind people.

• main reason is that it is very strongly based on visual map. Remember how unusable StreetComplete was when just background map become invisible on old androids in #5554? Now imagine if all quests were also placed linearly one next to the other, without any spatial relation. Even trying to make app like EveryDoor (which often claims the map is not really needed there, which is why it gets so little space) would be huge effort, and it is significantly more prepared for that then StreetComplete.
• some quests are just unsolvable to them (e.g. is this lit, what's the structure of this bridge).
• other quests are theoretically solvable, but would take inordinate amounts of time, especially given GPS and other inaccuracies (i.e. is this waste basket still here, where "here" could mapped +-20m anywhere around, and GPS error could add its errors, would make a 2-second quest for seeing person into 10-minute inch-by-inch scanning for blind person). That is not good use of anyone's time, nor respectful.
• some quests might only be solveable with help of very advanced AI which does not need human verification (e.g. what are the opening hours here?), by which time we don't need human mappers at all.
• some quest might be easily solvable (like Does this crosswalk have tactile paving on both ends, or Are there sounds signals for the blind here), but:
  • those quests are in minority
  • GPS positional errors and map inaccuracies make them hard to know which quest is being asked exactly (there are 4 crosswalks usually even for one crossing!)
  • SC would need to heavily modified to allow conveying geospatial relative positioning - i.e. it should give reference not only where is current quest located (e.g. 4 meters ahead at 2 o'clock), but also for getHighlightedElements() (e.g. where are other crosswalks in relation to this one). Also navigation through those announcements would need to be custom to allow easy and fast skipping, backing and repeating. And it would absolutely need reimplementing compass mode from #3377
  • even with all that, the chance of mapping errors would likely be significantly higher for blind persons, probably necessitating multi-people verification of answers, which need separate servers and APIs.

IOW, IMHO it would likely be significantly easier to make a no-screen quest-based OSM mapping app for blind people from scratch for few quests which are more easily solvable by them (perhaps stealing a few functions for API access and quest parsing), then to attempt to patch StreetComplete and MapLibre with enough functionality for it to be usable for blind people (and then telling them that they can't solve 95% of the quests anyway).

That being said, I'd love to hear concrete ideas / examples how SC (or SC-alike app) could actually be made usable for the blind; but to me it seems any attempts (apart from perhaps complete rewrite from scratch in completely different fashion) would be more of a "feel-good" action than actually accomplishing useful purpose (a prospect that makes most of blind people that I know more annoyed than anything)

[rugk]

Maybe you are right and you make good points, but one thing: accessibility is not only about blind people, but also about:

• temporary/situational problems, like e.g. being blinded by sunlight and you cannot read the map
• in general also seeing impaired people, this does not have to mean you see nothing at all, but maybe that tiny little informational text is unreadable that advises you on some important aspect for solving a quest
• generally other impairments like hearing problems, impairments for text understanding (language or complex it etc.) or so

Some concrete usual improvements that can be checked here:

• making sure the app works properly of font sizes are increased
• making sure it works if you have a high contrast mode or generally a hight-contrast map (design) could benefit
  • this can mean improving the default contrast, but also…
  • and/or having a special high-contrast map that mostly uses black and white (maybe enabled when the os asks for high contrast)
• texts should be clear and understandable, again a thing many people will benefit from
• even more, the app could be localized into a simple plain language, which many languages have, which can be easier to understand for many people (not sure how to do that technically and if Android even supports it, but generally)
• …

See https://web.dev/learn/accessibility/why
Accessibility is a broad topic and term, so this means much.

This issue was also just meant as a starting point to get the attention and do some advocacy. Obviously this can (and should) be integrated into the development in general. I am by no means an expert in that field, so I am sure much more can be done.
and if the UI is redone I guess this is a good point to keep that in mind.

Also, I think it would be very beneficial to people who can make use of such a quest, to also know aor even collect the data themselves. As said, maybe not all quests or so, but well… this can be customized.

[westnordost]

When big fonts lead to glitches in displaying the UI, this is something we should look at and fix.

[matkoniecz]

Similarly if things break in high contrast mode maybe it is fixable but would require specific report (including info how to get that high contrast)

[mnalis]

in general also seeing impaired people, this does not have to mean you see nothing at all, but maybe that tiny little informational text is unreadable that advises you on some important aspect for solving a quest

True. Are you aware of Android built-in accessibility features addressing those (without needing specific app support)? One is (for small visual impairments) just enlarging fonts. For larger visual impairments, there is magnifier tool (which allows arbitrary zoom on any parts of the screen, activated by gesture or physical keys). Both seem to work well in SC (but see below).

We also try to accommodate color-blindness (although newer androids seem to have features to help partially address that issue too).

generally other impairments like hearing problems, impairments for text understanding (language or complex it etc.) or so

I don't think people with hearing problems will have issues with using StreetComplete (I've always used without it producing any sounds -- except that one time!)

As for the simple and clear language, we already strive hard to do it that way (and we do I pretty good job generally, I think!). But if you spot unclear language somewhere, please do open an issue!

There are fine motor control issues, but I don't think that those can be easily solved with current concept of icons on a map (icons could only made very slightly larger without making map display mostly unusable); and we already try to make all buttons big enough for "fat fingers"

Some concrete usual improvements that can be checked here:

And that is great @rugk; as things that "can be checked" can be done by anyone (including you or me) without burdening main developers (who have full hands of stuff we can't do), and if an actionable issue is detected, it can be reported as a new (actionable) issue, explaining exactly what the issue is, and proposing solution(s) how we think it may be solved.

• making sure the app works properly of font sizes are increased

I've checked this one, and it seems to work mostly fine, with one bug I've just reported: #5881 !

• making sure it works if you have a high contrast mode or generally a hight-contrast map

It seems that android-wide contrast does not affect SC map. SCEE however has special high-contrast theme, so you may want to try out how it works; so perhaps it could be included in SC if it turns out to be good at solving accessibility issues!

I am by no means an expert in that field, so I am sure much more can be done.

Wait, is that a typo (i.e. "you are not sure much more can be done") or some sort of willingly acknowledging Dunning-Kruger effect? 😃

The most obvious example I see are the quest icons: Do they have an alternative text describing the image?

As for the original issue from 2017.; that seems to have solved itself - any icon on the map provides a question (and longer explanation if provided) just by clicking it; but also there is a list of all quest with their icons in Quest presets under settings...

This issue was also just meant as a starting point to get the attention and do some advocacy

If you are interested in putting in time to work on this, good strategy might be to approach some of the groups with specific disabilities who might be able to use most of the app (e.g. so visually impaired yes, but fully blind probably not) and asking if they'd like to help evaluate possible issues with app (with very short introduction what SC app does and how OSM data it updates might help them). if you catch their interest; they'd likely be very adept at finding accessibility issues, and also likely have better hints at possible solutions than we have; and even if they don't have a suggestion for a fix, when issue is identified, one could ask on https://ux.stackexchange.com/ or similar places for directions how to solve it.

[rugk]

some of the groups with specific disabilities who might be able to use most of the app

As indicated, we could get a free a10s review by https://github.com/KreerC/a11ybuddy?tab=readme-ov-file#free-consulting-offer
I just don't feel like I am allowed to (file a) request (it) and I am not even sure if it is wanted. But maybe I'll ping @KreerC and they read it and can provide more information.

As for this "typo", well lol:

I am by no means an expert in that field, so I am sure much more can be done.

I rather mean "I guess I may overlook many stuff that can be done/which should be accounted for" rather than "I know for sure there is stuff to do" haha…

And yes, going forward by reporting small issues would certainly be the way to go! Also note my listing was more general examples to explain the concept (and what may need to be checked), not that I claim SC has a flaw there.