The Three Letter Cure for Web Accessibility and Discrimination Problems
http://lauren.vortex.com/archive/001136.html
A few months ago, in "UI Fail: How Our User Interfaces Help to Ruin
Lives" ( http://lauren.vortex.com/archive/001112.html ), I discussed the
many ways that modern Web and app interfaces can be frustrating,
useless, and even painful for vast numbers of users who don't fit the
"majority" category for which app and Web designers tend to build their
user interfaces.
This doesn't just include rapidly growing population segments such as
older users, but pretty much anyone without perfect vision and motor
skills, or involving the many varying levels of literacy, or slow and
unreliable Internet connectivity. It's a long, long list.
The topic is in focus again with the introduction of Google's new
version of Google+, which so far, frankly, is an accessibility
disappointment, in key respects seemingly moving backwards.
However, the G+ redesign is not my focus for today, since it is
currently opt-in (and easily opt-ed out later if desired) and is very
much a work in progress as the G+ team receives user feedback. There
have already been some associated improvements in that regard, and I
hope to see more. So a detailed discussion of the new G+ UI can wait for
now.
What can't wait are the overall problems of how user interfaces can
easily create accessibility problems and resultant discrimination
against vast numbers of users and potential users.
This is by no means a Google-only problem -- it cuts across the entire
Internet industry.
And in most cases it's not a purposeful decision to discriminate -- it's
the natural outgrowth of mostly relatively young persons (who else could
keep up with the coding loads fueled mainly by strong coffee!?) who
build interfaces that they believe will well serve the "bulk" of their
users.
Of course, at the scale of these companies, those users outside that
"bulk" can represent hundreds of millions of individuals who can be
easily left behind, users who in many cases could most benefit from
these technologies.
An obvious question one might ask is why aren't there usually options on
these interfaces to serve different kinds of users? Why not an option
for higher contrast text? Or for easier scanning by audio screen
readers, or larger targets for mouse clicking?
The short answer is that in many quarters of our industry, options per
se are something of an anathema, to be avoided whenever possible.
Interface designers tend to feel that with enough effort and study data,
they can create a singular interface to serve everyone (or at least,
everyone they feel really matters at the moment).
What's more, options do add complexity of their own to UIs --
potentially confusing to users -- and can make code maintenance more
difficult and expensive.
Yet "universal" interfaces are increasingly showing their fundamental
limitations.
Do we need to invent some sort of new technology to solve this problem?
No.
Because the solution, while not a panacea in and of itself, already
exists.
That solution is the A-P-I: Application Programming Interface.
Simply put, APIs are mechanisms through which programs and systems
permit other programs and systems access to various of their internal
functions.
APIs already keep much of the Net running, one way or another.
A visit to Google's API Explorer
( https://developers.google.com/apis-explorer ) yields a long list
involving ads, maps, email, files, security, content, and much more --
all of which exist to permit third parties to write software that can
access key aspects of Google systems and then read/write/process/display
settings and data in direct conjunction with those third-party systems.
By now you likely see where I'm leading.
If stable, supported user interface API access were available for
services like Google+ -- and the many other firms' systems around the
Net that currently put users at an accessibility disadvantage -- it
would be possible for third parties (commercial, nonprofit, individuals,
etc.) to write their own customized interfaces for these services to
meet specific accessibility needs.
Visually enhanced high contrast interfaces? An interface much easier for
someone with limited motor skill acuity? There are a vast range of
possibilities for customized interfaces to help an enormous number of
users, all of which could operate via the same essential kinds of API
mechanisms.
Without APIs, such customized interfaces are usually impractical.
Attempts to create customization based on "screen scraping" and
techniques like page display CSS modifications are subject to
potentially breaking at any time, whenever the underlying format or
structure of displayed pages are altered.
You must have stable user interface APIs to make this work.
And you can also probably guess why APIs for user interfaces are often
resisted by firms.
Such APIs have to be built and maintained, and kept compatible as their
mainstream interface and backend systems evolve and change.
There's also some loss of control. What's emphasized on a page. Where
ads are placed (and how easily ads might be blocked). What's shown?
What's hidden? Does any given API-based interface actually make things
easier or more confusing for any given user? Can API-based interfaces be
leveraged to falsify data or enable scams?
So the calculus around all this is decidedly nontrivial.
But these are all solvable issues, given the will and resources to do
so. User interface API guidelines and usage standards can be
promulgated. Methodologies for the inspection and certification for such
API-based UIs are relatively straightforward to postulate.
One thing is certain. These accessibility issues must be solved. The
status quo is increasingly untenable, leaves enormous numbers of persons
in the dark, and potentially invites both litigation and heavy-handed
regulatory actions.
Universal "one size fits all" user interfaces are no longer acceptable
from the major Web players.
Properly designed and managed, APIs provide us with a practical and
potentially highly fruitful way forward.
Let's get to work.
--Lauren--
Lauren Weinstein ([email protected]): http://www.vortex.com/lauren
Founder:
- Network Neutrality Squad: http://www.nnsquad.org
- PRIVACY Forum: http://www.vortex.com/privacy-info
Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info
Member: ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com
Google+: http://google.com/+LaurenWeinstein
Twitter: http://twitter.com/laurenweinstein
Tel: +1 (818) 225-2800 / Skype: vortex.com
I have consulted to Google, but I am not currently doing so.
My opinions expressed here are mine alone.
_______________________________________________
pfir mailing list
http://lists.pfir.org/mailman/listinfo/pfir
