Re: Working Group Decision on ISSUE-131 caret-location-api

On Sat, Apr 30, 2011 at 1:57 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> I dispute that canvas can be made accessible in general. Has anyone
> demonstrated that it's technically possible to make games such as
> first-person-shooters, "Asteroids", or "Pac-Man" accessible to blind users?
> How about fractal generators, seam-carving demos, Google Street View, or
> Google's Body Browser?

I think our capacity to make applications that *appear* to depend on
sight accessible to people who do not have functional sight (assuming
that's what you mean by "blind" here) vastly exceeds the actual research
and development resource society allocates to doing so.

Allow me to try and tackle your particular examples, with the caveat
that any deficiency in the following is likely to reflect limits to my
current imagination, rather than absolute or even realistic limits to
what is "technically possible".

ARCADE GAMES: There are blind users who learn to play mainstream games
using audio cues, there are developers who work on making mainstream
games playable using plugins, and there are also audio games
(http://en.wikipedia.org/wiki/Audio_game). Examples that can be paired
directly with your examples include:

   * AudioQuake, an audio mod of Quake:
     http://www.agrip.org.uk/about/
   * Back in 2006, Thomas Ward was working on an audio game version of
     Asteroids. I don't know the ultimate fate of that project, but
     there are archived discussions of his work on the Audyssey mailing list:
     http://audyssey.org/pipermail/gamers_audyssey.org/2006-October/007991.html
   * Various Pac-Man audio games which went on sale back in the '90s:
     http://www.audiogames.net/db.php?action=view&id=pacmantalks

FRACTAL GENERATORS: Just as you can generate visuals from fractal
equations, you can generate audio. See for example:

    Sukumaran, S. (2009), "Generation of Fractal Music with Mandelbrot
       Set", Global Journal of Computer Science and Technology.
       http://computerresearch.org/stpr/index.php/gjcst/article/download/89/82

Alternatively, you could allow blind users to explore images generated
from fractal equations by printing them out using braille embossers or
using audio feedback as the user's fingers interact with a touchscreen.
At the high-end of what's possible, you could use a dynamic audio-haptic
pinmatrix map:

   http://www.output-dd.de/de/project/interactive-haptic-map-visually-impaired

SEAM-CARVING DEMOS: An accessible seam-carving demo could be implemented
the same way as an accessible fractal image equation. In passing, it
strikes me that the identification of seams in images is likely to have
significant overlap with the automatic audio-haptic mapping of visual
information.

GOOGLE STREET VIEW: Generally, there seems likely to be significant
cross-over between the task of accessifying Google Street View and the
task of accessifying virtual worlds such as Second Life, which is the
subject of various research projects, such as IBM AbilityLab Virtual
Worlds Accessible User Interface:

http://www-03.ibm.com/able/projects/virtual_worlds_accessible_UI.html

I think Google Street View is really a technology featured in various
Google products, rather than a product in its own right and it's hard to
discuss specifics of how a such a technology could be made accessible in
isolation from the end-user value it supplies in a particular product.
For example, Google Maps already surfaces a lot of blind-accessible
information, such as textual addresses, directions, and venue reviews.
To some extent this *is* the accessible form of Street View.  You could
allow blind users to roam in Google Street View in Google Maps by
marking visible landmarks, exposing clickable waypoints in the
accessibility tree, and crowdsourcing and web-aggregating descriptions
of locales.

GOOGLE BODY: The purpose of this product seems to be explore anatomy.
Human anatomy can also be described with text, braille embossers, or
audio-haptic mapping.

Bringing this discussion back to the features that user agent
implementors need to provide, the seeming impossiblity of making all
experiences accessible to everyone does not devalue making as many
experiences accessible to as many people possible. Just like the
seeming impossibility of curing everyone of every ailment does not
devalue medicine in general.

Even if it were impossible to make the applications you mention
accessible to people who cannot see, does not mean that there would be
no value in making other applications, such as cloud-based business
applications, accessible. Failing to do so could easily mean that a
particular software solution could not be adapted by an organization
without discrimination against blind employees.

We must also remind ourselves that accessibility is not just about
people who cannot see, but also about the entire range of human
differences. Accessibility features that help the blind may also help
people who have partial sight or limited mobility, as both magnifier and
voice control applications using system accessibility APIs. Even if
an application cannot be made blind-accessible, it may be possible
to make it accessible to other groups using the same features.

> The "shadow DOM" proposal can be used to make some canvas applications
> accessible to blind people, but there you're really just creating
> alternative interfaces that bypass the canvas altogether. That can be
> done without specific canvas accessibility APIs and you haven't really
> made the canvas itself accessible, you've made the underlying
> application accessible.

This doesn't make much sense to me. It seems similar to arguing that a
exposing a desktop application to an accessibility API doesn't make the
application accessible, because you've created an alternative interface
to it.

In any case, the Change Proposal under discussion here is primarily
aimed at enabling access for people with at least partial sight - people
who need magnification or special highlighting of focus, caret, or
selection - not blind people who cannot see the canvas at all and
are effectively going to interact with the sub-DOM.

--
Benjamin Hawkes-Lewis

Received on Saturday, 30 April 2011 18:44:12 UTC