W3C home > Mailing lists > Public > public-rqtf@w3.org > July 2019

Draft #2: W3C Workshop: Transportation Data Models -- Due Today

From: Janina Sajka <janina@rednote.net>
Date: Mon, 8 Jul 2019 16:29:16 -0400
To: W3C WAI Accessible Platform Architectures <public-apa@w3.org>, public-rqtf@w3.org
Message-ID: <20190708202916.GE1832@rednote.net>
Janina Sajka writes:

Herewith a second draft to my draft posted last week here:


Since this position statement is due today, any suggestions on this
draft are needed right away. Thank you in advance.

I propose that we consider a Call for Consensus in APA on this statement
in the next weeks, so that it can be presented as an APA position. We
can discuss this suggestion on list and on our teleconferences upcoming.

Also, I have registered for the conference, but I would be perfectly
satisfied if someone else is able to actually represent APA at this
event.  We will take up the issue of who might be able to attend and
speak on behalf of APA and of accessibility in the days that follow.

Cut Here ...

***One Size Can't Fit All***

Supporting the accessibility needs of persons with disabilities in our
emerging transportation industry will require personalized adaptation in
service delivery. Because the user can't change, the industry must adapt
its data modelsto accomodate the varying requirements of different

We note this requirement requires strong privacy protections because the
user is voluntarily disclosing data about themselves they would prefer
not to broadcast to any and all eavesdroppers. It is well known that
users who are persons with disabilities will disclose the nature of
their disability to a service providing goods or services of particular
value. However, this cannot be seen as license to leverage that
information by selling or otherwise exposing that data to third parties.

We would characterize this data modeling requirement as personalizable
onboarding/offboarding support.  Here are a few examples to illustrate this

*	Some transport customers will require wheel chair accessible vehicles.
	Others may only need to store their chairs securely before occupying a
standard passenger seat. It must be possible to order up a wheelchair
accomodating vehicle through the standard requisitioning process,
whether by the ride or by a calendar interval. It must be possible to do
so without requiring the user to provide this nonvarying data point with
each request regardless the local language.

*	Persons using wheelchairs have a very strong requirement to be
*	delivered to a location which allows them to proceed in their
*	wheelchairs. This is often not the front entrance to a large
*	facility such as a train station. It may even be a location
*	inside a secured facility such as a sensitive research campus.
*	Think the National Institutes of Health (NIH) or the National
*	Institue of Standards and Technology (NIST) in Montgomery
*	County, Maryland in the U.S. In many cases this accessible
*	offboarding will require communication to the appropriate
*	officers at the destination facility so that the customer
*	needing assistance can be met and assisted personally when the
*	vehicle arrives.

*	The industry already has rudimentary awareness of its onboarding responsibilities	in that they typically provide a photo and the
*	license plate designation of the requisitioned vehicle to the
*	ordering customer for reasons of security. However, blind
*	customers aren't served by license plate numbers and transmitted
	photos of their drivers. Rather, they need the driver (or
	vehicle) to identify themselves upon arrival. In the
	circumstance of a customer who is blind, it's the user's name
	and photo which should be transmitted to the vehicle driver with
	a note reminding the driver that it's their responsibility to
	identify themselves as the driver of the requisitioned vehicle
	and to guide the individual to the vehicle. Furthermore, we
	likely need a mechanism for a vehicle to identify itself upon
	arrival to the user's smart device. Various strategies for
	disambiguating which vehicle is intended for whom will be
	particularly important in high traffic areas such as airports.

*	Similarly, robotically delivered parcels will need to guide
*	blind customers to the retrieval of their goods, e.g. "beep
*	beep, your pizza is here," i.e. at the locus of a sonic alert.
*	The data model should support visual and sonic alerts on a per
*	user need basis.

*	App based transport services today provide a compelling payment
	mechanism that avoids requiring the international traveler to possess
and exchange foreign currencies. However, they also need to facilitate foreign
language communication of key personal data, e.g. how do I tell my Uber
driver: "I'm blind, so you need to see me and identify yourself to me as I
won't be seeing you when you arrive?" What's the word for "blind" in Chinese?
French? Etc? And, why should I have to learn it when the app can
communicate my critical factors on my behalf?

***Internal Systems Assistive Technology Support***
Systems internal to any vehicle should interface readily with any
customer's personal devices, including their assistive technologies.
This clearly includes on board entertainment, but also command and
control of any autonomous vehicle to the full extent that vehicle is
autonomous, whether it's an automobile or a private jet.


Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa
Received on Monday, 8 July 2019 20:29:38 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 17 January 2023 20:26:46 UTC