Distinguishing different aspects of accessibility (was Re: Marking up links to alternative versions of content)

At 11:32 +0300 UTC, on 2007-08-02, Henri Sivonen wrote:

> On Aug 2, 2007, at 00:09, Sander Tekelenburg wrote:

[...]

It appears that at least some of the confusion in this debate is due to all
of us mixing up user needs, authoring needs, UA implemantaion
(im)possibilities and perhaps more. Hence the subject change, and my attempt
below to be overly clear about those distinctions. Hope it helps.

> Are you advocating that sometimes browsers should offer all
> "equivalent" versions to the user (not "mutually exclusive") but
> other times browsers should pick one of the "equivalents" and
> suppress the alternatives from the presentation (what I meant by
> "mutually exclusive")?

I'm saying that a user may have a need to consume more than one equivalent.
(Chaals, Gregory, you  and others have all provided convincing arguments for
that need.) I'm further saying that therefore UAs must make it possible for
that user to access all equivalents. (I mean that in the broadest sense. If,
as Lachlan and you suggest, authors are to provide all equivalents through
prose, without any special markup, UAs would need to do nothing to fulfill
this need. But it's still important to define this need, because some other
approach might require UAs to actually 'do something' to fulfill this need.)

However, a need to be able to access all equivalents is not the same as a
need to always have all equivalents presented. (When some equivalent cannot
be consumed by a user, that equivalent should not be forced upon the user --
the user may have disabled sound or images, for instance.) In fact, for most
users in most situations the ideal presentation will be to be confronted with
one equivalent. (A user wants to see a movie. Being forced to choose from
transcripts, captioned versions, Real, WM, QT, versions, etc. will confuse
many users. In other words, forcing users to choose from equivalents
generates serious usability problems.)

Therefore I'm saying that users should by default be confronted with only one
equivalent. (With "default" I mean both te UA's "factory defaults" and user
configurable default. Factory default, because being confronted with one
equivalent will be the most usable for most users. User configurable default,
because an inivdual user may have the real needs to [1] change which type of
equivalent is presented by default and [2] override that in iindividual cases
and [3] to have equivalents presented simultaneously. )

[Note that I'm only talking about user needs here. Not authoring mechanisms,
not UA implementations. Let's try to stick with that. Too often when a need
is being discussed, it is responded to by a "that's not implementable". Some
solution may not be implementable, but until we agree on the needs, it is
useless to look at the problems of perceived solutions. Let's all try to take
this one step at a time.]

[The next bit jumps from user needs to authoring]

[... prose vs markup]

> Prose is human-to-human communication. What that prose says
> communicates (dis)confidence about the nature of the alternative to
> another human more effectively than a necessarily simplified machine-
> readable markup assertion.

I honestly cannot follow. A boolean leaves way less room for misunderstanding
than human language.

Yes, I see that human language can in some cases help identify what the
author means with "equivalent" -- it might not be what the user means with
"equivalent". But given how extremely talented most people are at
miscommunication even when they try to understand each other, relying on
human to human communication for this seems totally unrealistic for most
people in most cases.

[Next, we return to user needs]

>>>   * Prima facie, I trust software performing the selection for me
>>> based on said labeling even less.
>>
>> Do you not trust your anti spam filter?
>
> Not fully.

Exactly. You need a default behaviour, with the option to override. No
default behaviour -having to manually decide what is spam- is not realistic.
So you rely on its default, but need the possibility to override.

>> Do you not trust your browser to block pop-ups?
>
> I don't need to, since mine tells me when it blocked a pop-up, so if
> the indicator appears in response to an event generated by me, I can
> easily identify a false positive.

Exactly. You need a default behaviour, with the option to override.

[Below, we jump to a risky mix of user needs, authoring, and UA
implementations.]

[... authoring techniques]

> I would assume that editing some invisible metadata is a bigger
> hurdle than writing text and making a plain link.

There's that incomprehensible use of "invisible metadata" again :) When we're
talking about authors, prose and markup are equally visible.

[...]

>> it can for instance be useful to consume audio and its transcript
>> simultaneously. For that particular case, the user could load the
>> audio file into an extrenal player.
>
> In the external player case, browser being too smart is worse *in
> practice* than relying on the user's knowledge of what files (s)he
> can play outside the browser.

I can't follow. I'm not talking about browsers being smart. I'm talking about
users making decisions that suit them best. There is nothing new about
browsers presenting some content inline and passing other content on to other
applications. Within the 'classic accessibility context' consider viewing
images with lynx. Within the "popular browsers context", consider Real, QT or
WM content being loaded in an external helper, mailto links being handed off
to a dedicated email app, etc. UAs also typically are configured to apply
some default, yet to allow overriding that in individual cases. (Click to
load PDF inline, Option-click to download and hand off to some other app. For
instance.)

[...]

>> Of course there are ways to make some sense out of non-structure,
>> but it'll
>> always be easier to make sense out of structure. The result will be
>> better,
>> the work will be easier, the cost lower, etc.
>
> Actually, that's not necessarily true when people have an incentive
> to lie in their metadata/markup for SEO purposes.

Yes, that's a valid argument. But it's not the argument that ends all
arguements. I believe there are two, perhaps more, counter arguments:
[1] Even despite its massive misuse, @alt appears to be incredibly valuable
to those who need it. That suggests that lying hurts, but is not as deadly as
is claimed.

[2] An indexing bot can see that 'invisible metadata' conflicts with 'visible
prose' and decide to therefore ignore the visible prose. (When the visible
prose of a page is about turtles, and the invisible metadata about porn, for
instance.)


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Thursday, 2 August 2007 16:29:36 UTC