W3C home > Mailing lists > Public > public-vocabs@w3.org > March 2015

Re: Accessibility of places for schema.org

From: Liddy Nevile <liddy@sunriseresearch.org>
Date: Wed, 11 Mar 2015 08:42:10 +1100
Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>
Message-Id: <50D776A2-6BB4-4897-8583-A7F463E47934@sunriseresearch.org>
To: chaals@yandex-team.ru
mmm… in fact I think there are some good places to start. We did try working on this as part of the ISO AccessForAll work and there are lists of things that are objective, of the kind Charles is talking about. I think one good list was one that is used in Canada … I can try to find it again..


On 10 Mar 2015, at 4:16 pm, 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 Tuesday, 10 March 2015 21:43:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 March 2015 21:43:46 UTC