Q: support for speech separately? just taking advantage of the idea that if
you’re doing accessibility support, you might as well add the ability to
access the OS speech engine for non-accessibility reasons?
It makes sense, but at the same time this is slighty more towards
SDL_mixer or SDL_sound’s territory. Exposing speech engines via paired
SDL_RWops, AND letting a satellite library use that + a synthesiser
(in case the OS stuff won’t work for some reason) to provide the
generic manifestation is probably the right way to go.
I was going to include a link to a page talking about a cheap (though
imperfect) English speech synthesis algorithm, but I can’t seem to
find it (maybe it was something about detecting syllables instead of
actual text-to-speech stuff?).
SDL_mixer doesn’t actually have access to window events, SDL
internals, or anything of the sort. Speech synthesis is only “part
of sound” on Linux?anywhere else it’s an OS call you feed a string
to. And again, since when did SDL_mixer handle your mouse?
Although I’m kinda agreed that having multi-platform accessibility wrapper
is a good thing, does it really fit in what SDL is aimed for ?
SDL is aimed at being a platform-abstraction layer: it’s a DOS-weight
partial-OS specialized for multi-media applications. Some of the
people that will want to use these applications will need
screen-reader or similar support. SDL should therefor provide both the
portions of the system that SHOULD be in SDL if they are to function
correctly, AND enough to use that same support in a platform-agnostic
manner.
Thus: this is necessary.
Okay, for just one moment I need to take off the busy and disgruntled
developer from the days of yore hat.
I remember back in the day someone took old-school Quake 1 and redid
its sound system completely to use positional audio and otherwise
did away with the sound mixer’s (many) quirks. Then they blacked the
screen. The blind players wiped the floor with the sighted ones.
Menus were not accessible though because it was a research project
rather than an intent to create an accessible FPS. And the results
of the “research” were that the game wasn’t “fair” for the sighties.
Give people back their screens and give everyone some optical camo
(Snake? Snake?! Snaaaaaaaaake!!) so that people cannot be seen any
further away than they could be heard and use that kind of positional
audio setup, and it’ll be a fair deathmatch. 
I don’t see many people going out of their way to make games that are
accessible, but if we can help make it easier for them to do it, that
should exist somewhere. Sik says it can’t really go somewhere other
than SDL, and knowing a little about accessibility toolkits (though
not a lot admittedly), he’s right.
Some people on this list already know that I am legally blind. I
don’t actually need speech output in anything really, but I often use
it anyway to save on eyestrain to read long posts and whatnot. In
any game I can configure the font size, I never even worry about it.
And the fact is that there are a whole lot of games I would LOVE to
play if I could read the damned in-game text. Fallout, *craft, you
name it.
But I can’t. Because ultimately I’m legally blind. I’m never going
to be able to read small print in a game, certainly not real-time.
It’s one of the things on a list that’s growing shorter all the time.
In the past 20 years, I’ve been able to drive cars, shoot guns, and
use gadgets so visually-oriented that they don’t actually have
physical buttons. But I still can’t play Starcraft. Not because
Starcraft is something unplayable, but because the text is too small
and I can’t make it bigger enough to read without stopping the game
and pulling out a magnifier to slowly read my screen.
And while I doubt adding OS-abstracted events for “the user wants
read”, “next/previous item”, “adjust control up/down” (which
if you think those things belong in SDL_mixer, I want a crate of
whatever you’re smoking). Speech output on every platform that isn’t
Linux is completely different than PCM audio as well, so there’s no
reason why SDL’s implementation shouldn’t include the remaining
OS-abstracted calls such as maybe SDL_AccesSetAccessLabel,
SDL_AccessSpeakText, and SDL_AccessShutUp (I’m now lobbying for that
last one as the function name, even though I’m sure the idiom doesn’t
fit other languages?) These usually work without even thinking about
opening a sound device, and probably that’s true even under Linux if
it works at all. Most OSes now have the ability to speak a bit of
text without the user setting up any accessibility features, so the
SDL_AccessSpeakText function might be available by default on many
platforms. Linux ain’t one of them.
Actually, it’s not unheard of for the “spoken” text output by a
screen reader to go to a Braille terminal rather than a speech
synthesizer. Some special-purpose programs over the years output
different things on speech and Braille devices, but that’s not
something SDL could ever even hope to do in an OS-independent way.
The software that can is pretty much written for embedded devices.
I hope you’re not saying that accessibility shouldn’t be done,
because I would find that deeply offensive in 2015. Most of the
civilized world has concluded by now that the disabled should not be
excluded as a general rule. That wasn’t possible under DOS, but it
sure is possible today. If Apple can design a buttonless interface a
blind person can operate, the NFB can design a car that we can drive
blindfolded (not that drives itself mind you, but that a blind person
can drive), then Xerox can make copiers that we can use, Panasonic
can design microwaves we can operate out of the box, OSes can feature
accessibility from the installation onward, and SDL can provide a
handful of functions to shove speech out to the OS and pass the
special keyboard or gesture commands back.
If you’ve got a problem with that, I suggest you might want to
migrate to the 21st century. Because the attitude that the disabled
aren’t worth consideration or qualify as “bloat” or “cruft” is the
kind of thing that can and does result in very expensive lawsuits
with damage awards these days. And rightfully so, if filed under
those circumstances. You would not tolerate discrimination against
someone because of their skin color or sexual orientation or religion
anywhere else, so why the hell should we accept status as second
class citizens of the modern world?
Now, if the thought never crossed your mind, that’s one thing. Or if
you can’t figure out how to make something accessible, that’s also
fine. There are things I don’t know how to make accessible, and I’m
the blind dude on the mailing list. If I don’t know how to do it
even conceptually, how can anyone else be expected to have the
answer? That’s the biggest reason why I would argue that SDL’s
accessibility support would have to be thin, BTW?I can’t imagine how
else to implement it in an OS-agnostic way.
But when accessibility support becomes less about “didn’t” or
"couldn’t", and more about “won’t” or even “shouldn’t”, you better
believe I start getting surly.
I mean, is it
better to make it a separated library (and may be having a bridge to SDL if
it’s really need to) ?
Courts in the US have occasionally (it doesn’t actually come up often,
from what I understand) ruled that a law that was intended to require
business owners to be handicaped-accessible ALSO applies to web pages
(I understand that one of the major retailers got hit with this… and
lost). It’s very easy to infer that it’s binding on software in
general, thus it’s something that should be supported.
Moving it into a seperate library would add unjustified complexity to
programmers.
MANY websites are only “mostly” accessible. If you can basically
make it work more or less, even if it’s not easy, you don’t have a
leg to stand on to sue.
However, if you are a public commercial enterprise, and it is
actually impossible to access the checkout button of your website
without being able to see and click on it, there’s a problem. If we
then approach you with the problem and offer you the code to fix it,
and you REFUSE? Ask Target how that worked out when we sued them.
(Hint: They lost.)
Didn’t or couldn’t vs won’t or shouldn’t. Target argued that online
shopping was only for able-bodied people. The disabled could just
walk into their stores if they had a problem with the website. And
they shouldn’t have to go and make their buttons clickable just
because some disabled people couldn’t use their broken javascript.
That could have cost Target dearly, if we wanted to make it an
expensive lesson. But all we asked was that they fix it. Cost them
their web developers’ time to implement the fix and some court costs.
Likewise, we asked Apple to make the iPod accessible and they said
there weren’t enough blind people out there who listened to music for
them to worry about it. We educated them as to the depth of their
error in thinking. Again, it could’ve been a very expensive lesson
for them, but we went after fixing it more than a payday. And they
implemented the fix we asked for (spoken names of songs as m4a files,
along with the menus) because it actually was an easy fix.
But they also took the lesson to heart. The next iPhone had a screen
reader that was revolutionary. Webkit went from zero to accessible
in one major OS revision. Apple improved their magnifier and created
VoiceOver on the Mac. And Apple’s accessibility push was so complete
and profound that it literally forced Microsoft to do the same to
Windows 8?it no longer costs blind people $1000 on top of the price
of a computer for the privilege of being able to use it. (I wasn’t
involved in the Apple lawsuit at all actually, but I approve of the
outcome most assuredly!)
Including a few hooks for the OS’s own accessibility features won’t
make video games accessible to anyone. But putting the ability for
game developers to do it into games will hopefully encourage people
to at least consider it. After all, DOS couldn’t do unicode either
and SDL now does that exceptionally well. And some day, I’ll figure
out how it works and start using it. Because it’s worth doing for
the people who need it.
Also is it really needed to integrate the
functionality into SDL ? Can we keep them separated ?
Is it really needed to keep it out of SDL? No, it doesn’t have to be kept out.
Can we make them integrated? Yes, we can make them integrated.
It’s already been discussed that SDL fundamentally needs to be
changed to make accessibility possible, library or not. But as the
support required entails translating some system events to SDL events
and providing a wrapper around a system that fundamentally gets
passed a string when appropriate, I’d say it’s just as important as
supporting unicode, and for just the same reasons. You COULD put
that in a library. You shouldn’t though.
I’m just afraid that one day SDL might become one big monolithic platform
that handle everything even if only parts of it are really used in most case.
This is not an appropriate cause for fear, but instead for some
self-analysis. Many people will automatically have different ideas
about what should and what should not be in SDL. I think that textured
triangles (and maybe a batching system) should be in it. This is not
because you CAN’T do without them, but instead because those two
features allow both SDL and satellite libraries to do their jobs much
better.
Actually, I have interest in being able to backend SDL into libretro
for a few things, which largely involves being able to gut large
components from SDL as it is normally compiled/installed and build a
small one-target library. Probably a static one at that.
That would seem to run cross-purposes to things like adding lots of
features like accessibility, but so much of SDL is modular and the
modules don’t often have a huge degree of interdependency. That
doesn’t mean we shouldn’t exercise some stewardship over what does
and doesn’t go into the library, but it does mean that some things
should go into the library because they belong there, even if someone
else might find them to be unnecessary at this time. The renderer
for 2D games and the GameController API are examples I’ve cited of
this recently. The one is totally irrelevant to any modern 3D title,
and the other already is a helper lib that was just stuck in the
trunk because Valve wanted it for Steam. And today nobody would
really argue that either thing didn’t belong in SDL.
Extending SDL isn’t apocryphal, it simply needs to be restrained.
Adding a full GUI system? THAT would be taking things a touch too far
(we already have graphics, so the support that a gui satellite library
needs is already fully implemented).
Not only that, but GUI is such a nebulous concept that people’s needs
are going to be wildly different. The GUI I would need for a game’s
menus is going to be a lot more simplistic than you might want for a
3D modeling program. It doesn’t even make sense to implement one in
terms of the other most of the time.
SDL doesn’t do “everything”, and won’t with this extension either.
Now, if SDL directly integrated the satellite libraries? THAT would be
"doing everything".
What SDL is SUPPOSED to do is act as an abstraction layer, a
"quasi-OS" that provides you with a generic API for things that would
otherwise require entirely platform-specific code. This is what SDL 1
was created for, and this is what SDL 2 is designed for. This is why
SDL 2 allows you to specify your own OpenGL library, but doesn’t
actually implement one itself: that bit’s already abstract, the
problem is in the initialization.
I don’t see it as any way related to an OS. I see it as a way to not
care about an OS at all, FWIW. General rule in my mind is that
nothing outside of SDL should need to know about things like that.
In practice there will likely be some, but it should be limited.
“Does it make more sense combined or seperate?” is the question that
should actually be asked, because the ones you listed express the
implication that the correct answer is “Seperate”, regardless of
reality.
I see the following possibilities for any thing you might do:
- It should not be done anywhere.
- It should be done outside of SDL.
- It should be #2, but SDL needs to be enhanced so it can be.
- It should be part of SDL itself.
Normally, any public function in SDL makes its way into your program
via SDL.h. I can see that being otherwise for certain more internal
bits (say of the renderer) which are frozen for the current ABI and
exported so that you can extend SDL from the outside, but that aren’t
really intended for use by most programs.
I dunno if that’s a good idea, but it’s one that is rattling around
in my head.
JosephOn Tue, Dec 30, 2014 at 08:13:47PM -0600, Jared Maddox wrote:
(it just skips over Japanese text)