Re: Accessibility of places for schema.org

There are a number of web sites or apps collecting accessibility data on
venues, trying to be the "Yelp of accessibility" so to speak. It might
make sense to survey those for data fields that are already in use. Here
are just a few I found.

AbleRoad has four tabs with multiple ratings for different facets:
http://ableroad.com/detail.php?index=1&newID=reds-kitchen-tavern-peabody&s=
reds-kitchen-tavern&s1=peabody%20ma&cat=1&hide=0


Planat.com seems to have a single score for each of visually impaired,
hearing impaired and wheelchair-using:
http://www.planat.com/venue/19674


AXSmap has a series of ratings:
http://www.axsmap.com/venue/ChIJa-2hCM00K4gRMlSgKZjTTgA/?back=%3Fwhat%3DEve
rything%26where%3Dtoronto%26filter%3Dtrue%26entry%3D3


There is lots of data to work from.

-Madeleine

On 3/10/15 1:16 AM, "chaals@yandex-team.ru" <chaals@yandex-team.ru> wrote:

>Hi,
>
>there are lots of things that people might want to know about in regards
>to accessing a physical place (restaurant, bar, stadium, government
>office, etc).
>
>The initial use cases I want to address are:
>- people going to a place and wanting to know if their particular
>requirements will be met.
>- people wanting to provide more detailed information (e.g. in a review)
>about access to a place they have been
>
>Things like street gradient are useful for walking maps, but I propose to
>leave that until we have something basic, relevant to the above cases.
>
>I know there are vocabularies we could use for physical accessibility,
>but I am not sure that there are any appropriate to adopt as is. Like
>document accessibility, some of the important information is not at all
>specific to accessibility and should be handled in a more appropriately
>general manner, other information requires too much detailed knowledge
>for someone to successfully apply it to the wordpress page of their small
>businessŠ
>
>I also want to avoid encouraging a "checkbox approach" from data
>providers. "My restaurant is wheelchair accessible" may be true. But
>details, such as the toilets are downstairs, the sushi bar is designed
>for high stools, and the only table that a 34" wide wheelchair can get to
>is at the front door and only seats 4 is actually critical. Likewise, "I
>am ADA / DIN32983 / Š compliant" is unhelpful - most of the world doesn't
>know the details so it doesn't convey the information people need.
>
>Below are some things that are really important to people, just in
>matching the use cases I outlined. I suggest we and pick a couple of
>simple cases, and work out how to do those, using experimental property
>names to learn what actually works in schema.org's context, before trying
>to get this entirely right in theory. I don't have any special
>preference, although wheelchair access is a good place to start because
>it is relatively straightforward for people to understand.
>
>- General mobility requirements
>  + Do I need to go up steps? One, 3, many?
>  People with a heavy electric wheelchair have a hard time dealing with
>one step, unless they are with a big friend, while people with a
>"temporary" disability like those recovering from a leg operation may
>well be able to get out of their chair to deal with a few steps. Airlines
>make this distinction, as does a group of friends going to a pub.
>  + Can I navigate the space?
>  Blind people when alone may find a large open space such as a
>conference centre very difficult to navigate. The use of Talking Signs,
>floor-level bumps for canes, maps of the space can all make a big
>difference.
>  Likewise, distances and widths of passage matter to many people. A
>small wheelchair can get around corners a large scooter can't. People may
>be limited in how far they can walk from a car. And so on.
>- Noise, light, flash, etc
>  There are lots of people for whom ambient noise and light cause serious
>problems. People with common levels of hearing impairment cannot
>communicate effectively with high background noise, people on the autism
>spectrum or with photosensitive epilepsy or various other conditions can
>have serious physical reactions. And many more just want a quiet dinner,
>even if there is no physical problem from noise. Which is a reminder that
>we should not rush into this with a sense that we're dealing with a set
>of medical conditionsŠ
>- Information services
>  Audio loops (e.g. for concerts or announcement systems), captioning,
>sign language interpretation and the like can be useful, or critical -
>e.g. in emergency announcements. Braille menus are sometimes useful,
>dispensable in many cases, and problematic if outdated - and in our
>connected era an online menu is probably better. In eastern Asia, digital
>signs and kiosks are widespread and play important roles in providing
>information multimodally.
>  For the case of menus, we should already cover the required information
>under the accessibility of a creative work, but others are not so clear.
>
>cheers
>
>Chaals
>
>--
>Charles McCathie Nevile - web standards - CTO Office, Yandex
>chaals@yandex-team.ru - - - Find more at http://yandex.com
>

Received on Wednesday, 11 March 2015 13:59:16 UTC