I want to thank folks for this discussion so far. It has motivated me to keep seeking out more real-world perspectives on how OSM can be useful for accessibility. I’m sure we’ve only scratched the surface.
Nothing compares to software created by people scratching their own itch. Back in my days triaging bug reports for a major vendor of programming software, I was very impressed at the skill with which blind people have managed to use this software, which was never designed with screen readers in mind, to create quite sophisticated applications, primarily but not exclusively for other blind users. I thought I was adept at keyboard navigation until I saw the screen recordings they sent in.
I’ve been trying to encourage some developers from the accessibility community to get more involved with the OSM community, since they’re already using OSM data in their applications. In the meantime, I’ll share some highlights from recent conversations I’ve had with local accessibility advocates, as food for thought.
One person who uses a wheelchair actually didn’t seem very impressed that we have some coverage of curb cuts. To them, at this point, curb cuts are infrastructure for the general population, so of course we would have curb cuts, right? They aren’t against collecting this information by any means, but it isn’t a game-changer for them. They’re much more excited about the possibility of collecting entrance doors on field surveys, noting their locations and dimensions. As it happens, this same information would also be a game-changer for other OSM users, such as delivery services.
I heard feedback that a binary wheelchair key is too simplistic, even ignoring the nuances about where to begin and end these tags. After all, a nominally ADA-compliant clothing store can still be difficult to navigate in a wheelchair, whereas a non-compliant store may have well-trained staff able to help a wheelchair user get through the narrow doorway of a fitting room. This gets into subjective criteria that would be difficult or undesirable to model in OSM, but I suppose we should view wheelchair=yes as a “necessary but not sufficient” indicator, requiring data consumers to integrate with an external resource for more reliable information.
A blind developer who worked on Audiom told me he envisions a navigation application providing guidance instructions for navigating two-dimensionally along a sidewalk. In other words, even sidewalks as ways are insufficient; he wants sidewalk polygons! When I participated in the San José sidewalk import, we discarded the city’s polygon information in favor of straight-skeleton linear features, out of concern that even those simplistic ways would be too controversial within the OSM community. I have a feeling we’ll revisit that decision someday.
Even though that granular level of positioning would be quite challenging with the current generation of mobile devices, the developer did have some ideas about how micromapped sidewalks would be practically useful today. OSM could collect information about the kind of surface that borders the sidewalk – grass, dirt, a wall – so that an application could tell the user what to expect when shorelining. Sidewalk areas would make it easier to determine whether a tree, bench, or signpost could pose an obstacle when traversing a narrow sidewalk.
Finally, the point is well taken that not every person with mobility needs has the same preferences. We shouldn’t even treat accessibility as a binary cutoff between able-bodied and disabled. Walking around downtown San José with my parents, we often approach an intersection and wait there even if we already have a walk signal. We’re waiting for the next walk interval to start so they have the whole interval to cross the intersection at a more relaxed pace. Eventually I’d like to map crosswalk durations, not so much so that a router can micromanage our daily walks, but rather as evidence to encourage the authorities to more fairly balance the needs of motorists and pedestrians.