W3C home > Mailing lists > Public > wai-xtech@w3.org > April 2011

RE: suggestions for new roles and properties in ARIA next

From: John Foliot <jfoliot@stanford.edu>
Date: Wed, 20 Apr 2011 01:06:35 -0700 (PDT)
To: "'James Craig'" <jcraig@apple.com>
Cc: "'Steve Faulkner'" <faulkner.steve@gmail.com>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>, "'Richard Schwerdtfeger'" <schwer@us.ibm.com>
Message-ID: <07c901cbff31$dd97bae0$98c730a0$@edu>
James Craig wrote:
> > What makes you believe it's not?
> I'm not saying Steve's @aria-description proposal is unnecessary--I
> asked the question for the sake of discussion--but I usually feel the
> "separate but equal" approach is unacceptable.

Discussion is good, and I asked the question to probe your reasoning. I
respect your opinion, but also need for you to defend it if we are to
accept it. Like you, I accept nothing without reason and proof.

> I know you well, John, and it certainly seems like you're trolling. If
> we get into this, I'll have to set aside some time on my calendar, and
> you promised to buy the beer, remember?

Pick the time and place, and I will pay the first round at least, and
maybe even the second.

> Anyway, I won't get into a list
> religious war, but I will state a few opinions on the matter.
> This type of feature-not-intended-for-general-consumption tends to be
> forgotten, out-of-date, or even misused to the detriment of those it
> was designed to help. The aria-describedby attribute doesn't provide
> the description; it only makes it so the AT can perceive a relationship
> that's usually by the visual interface, but the description text is
> already there and readable to anyone, including but not limited to
> those with disabilities. There's no separate description for blind
> people. Make the main interface accessible and usable, and you don't
> need this type of thing.

I have no argument on your basic premise, but there are times and
circumstances when doing what you suggest cannot be done, for many reasons
(as articulated in Laura Carlson's research for longdesc). If the author
cannot place a longer description in "plain sight" on the same page, what
is the graceful degradation option? There isn't one (especially with the
current longdesc and summary situations). Authors need choices and viable
options, and the more choices and options we provide to make content
accessible, the better. 

Simply saying that this type of longer description should be included on
screen ignores certain realities in evidence on the web today. A
'superAlt' mechanism that extends what @alt delivers today is a
potentially useful mechanism that solves a real problem elegantly. When
Universal Design is not 100% universal, we then turn to Accommodation
mechanisms to 'top things up', and in this we have many, many examples in
our society today. (I have a photo of a wheelchair lift in a building,
where placing a ramp was an untenable solution - that lift is exclusively
for wheelchair users, but solves a real problem none-the-less - suggesting
that the building in question should simply ensure a ramp exists denies
the fact that in that circumstance it *cannot* exist.) 

> An old, but relevant article about the "separate but not really equal"
> approach to accessibility.
> http://www.wired.com/techbiz/media/news/2001/12/49195

A newer and also relevant comment comes from Kyle Weems (CSSquirrel): 

	"I have no qualms with other people using hyperlinks where they
desire to provide alternate text. However, as a designer, I object to
being told I must use those links myself. As you've pointed out on
Twitter, the current design of the comic page would certainly support a
hyperlink wrapping around the comic. However, my upcoming design already
has functionality mapped to clicking the comic, and won't have space for a
large "transcript here" hyperlink sitting around in plain sight (which
would be distracting for the 99% of my users that are sighted). In that
scenario, longdesc can and does serve my needs."

Choice is good!

Received on Wednesday, 20 April 2011 08:07:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:44 UTC