Re: Distinguishing different aspects of accessibility

At 12:28 +0300 UTC, on 2007-08-03, Henri Sivonen wrote:

> On Aug 2, 2007, at 19:20, Sander Tekelenburg wrote:

[...]

> If one wants to both have access to all versions available *and* not
> have them all offered up front, there needs to be a mechanism for
> indicating that there are other "equivalents" and a mechanism for
> bringing up a list of the other versions on request.

Agreed.

> Whether this is
> worth the trouble depends largely on how often users feel the need to
> inspect the list of alternatives anyway and how often authors would
> bother to produce markup in support of the mechanism.

Agreed.

Although it should be noted that the need of a few users may well outweigh
the practices of many authors. (Consider how @alt appears to be essential to
some users, despite it being largely abused.)

>> (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.)
>
> I'm not sure what you mean when you say "forced upon the user".

I'm thinking of, for example, the situation in which a web page contains an
embedded movie, as well as a link to a captioned version, as well an embedded
audio version, as well as a transcript. (Not to mention that all videos might
be offered in different file formats, in an attempt to suit individual ideal
accessibility.) In that situation users will need to choose between those
equivalents. They are 'forced' to do so.

> If
> access to all equivalents is to be provided, surely at least an
> indicator of the presence of other alternatives needs to be presented
> to the user. Does that count as "forcing upon the user"?

A mere indicator of the existence of equivalents would not. The actual
equivalents would.

Consider a browser that, in the chrome, indcates that one ore more RSS feeds
are provided. I can't speak for everyone, but it seems unlikely to me that
such an indicator would be experienced by users as being forced upon them.
(And if so, it would likely not take rocket science to allow users to
completely disable that indicator.)

If OTOH the user is confronted with both the page's content and one or more
RSS feeds, or links to them, the user needs to understand what RSS is, why he
might want to consume one or the other feed. Yes, he can ignore it, but it's
much easier to ignore that RSS indicator in the chrome ("consistency across
sites"), than what is presented n the web page's body.

> As far as user needs go, if a user who is not deaf has disabled audio
> in order to avoid disturbing other people on mass transit or in a
> shared office, (s)he probably doesn't want the UA to hide indicators
> that audio exists (e.g. links to audio files), because the user could
> choose to plug in headphones or revisit later if the text pitching
> the audio content makes it seem interesting enough.

Agreed. Equivalents need to be discoverable.

> Do deaf users generally wish that UAs suppressed or compacted
> indicators of non-decorative (decorative being those marketing site
> background jingles) audio content availability? (This is an honest
> question. I don't know.

I don't know either, but whether they do or don't, there's still the argument
that forcing users to choose between equivalents is 'bad'. If instead there
would be a mere indicator that equivalents are available (with a mechanism to
get at those equivalents), then I don't see a problem here. In that case, a
deaf user who would find it useful to know that sound is available can see
that, and one who does not appreciate that information can ignore the
indicator.

Note that I'm think of a general indicator here. Something that merely
indicates that equivalents are available, and that requires user action to
find out what the equivalents are. Not ideal, but hopefully good enough for
this discussion's attempt at understanding each other, might be a cursor
change on hover, and a listing and access to the equivalents through a
contextual menu. [But this is jumping to UA implementations again, before
establishing agreement on actual needs.]

> But I can imagine that being aware of the
> availability of audio content could help establish context even if
> one couldn't listen to the audio.

Agreed. Equivalents need to be discoverable.

> That is, would it be important to
> suppress or compact a link "Download podcast" if there was a link to
> transcript next to it?)

Unless I'm the only one who thinks that *many* users would be confused by
being forced to choose between equivalents, yes. Users are confused by having
to choose between QT, Real, WM versions of the same audio file. If we can
avoid that confusion (to some extent), it makes things easier for users. That
in turn would mean authors woiuld be more likely to provide alternatives --
the argument that it only confuses their audience having been diminished.
That *in turn* is good for users.

> Likewise, users who aren't blind but have disabled images or Flash   [...]

Same as above.

[...]

> Even if the users eventually wants to consume only one alternative,
> the hard part is making software make that choice *correctly* and so
> that the user has confidence in the software making the choice
> correctly. This involves having a DWIM engine.

Let's try to save that implementation debate for later and first try to
establish/agree upon what users need.

Btw, I don't see any need to worry that agreeing upon certain needs would
lead to a requirement for UAs to implement the unimplementable. It way well
be that we can't find an implementable solution for a problem. It's just not
very useful to discuss a possible implementation difficulty before we've
established what it is to solve exactly.

>> (A user wants to see a movie. Being forced to choose from
>> transcripts, captioned versions, Real, WM, QT, versions, etc. will
>> confuse many users.
>
> How's the browser going to know that *this particular time* the users
> wants to see a movie instead of skimming the transcript? [...]

Let's save that for later; try to define needs first.

[... mark vs prose]

> Suppose there are two files: PowerPoint and PDF. Also suppose the
> user has neither Windows nor PowerPoint but has OpenOffice.org and a
> PDF reader. Which downloadable is the user going to pick? Which one
> would the browser pick for the user?

By default, in the sense of "fallback", whichever is defined as preferred. A
sensible factory default would probably be PDF, but the user should be
allowed to change that default to PowerPoint.

[...]

> The user but not the browser can probably guess that the PowerPoint
> file is the master file and the PDF was generated from it.

Is that really relevant? If that's been the author's workflow, it might still
be that the author considers the PDF to be the 'main' document. Or that they
are equivalents.

[...]

> But what if the page said this
> <p>Presentation Foo Bar is available as a <a
> href="foobar.ppt">PowerPoint file</a> and as a <a
> href="foobar.pdf">PDF without animations</a>.</p>

I think this merely underlines that "PowerPoint" is not an appropriate
description of a *type* of equivalent (one reason why I have my doubts that
the type attribute could/should be used). Probably appropriate would:

<p>Foo Bar is available as a <a
href="foobar.ppt">animated presentation</a> and as <a
href="foobar.pdf">pretty text with images</a>.</p>

The *file format* can also be very useful information. That can be authored
using the approach I advocate in "User-friendliesr hyperlinks", at
<http://www.euronet.nl/~tekelenb/WWW/userfriendlierhyperlinks/>.

But the file format *alone* doesn't serve most users. Quite the contrary.
Many won't know what PDF is, let alone what PowerPoint is.

[...]

> the user could instead pick the PowerPoint file and
> risk font breakage and slight layout quirks in order to see animations.
>
> What would the browser pick and why?

By default, in the sense of "fallback", whichever is defined as preferred. A
sensible factory default would probably be PDF, but the user should be
allowed to change that default to PowerPoint.

>>> 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.
>
> Only to authors who use a text editor and look at their own markup
> source. With other kinds of editors even if the editor had UI for
> "invisible metadata", chances are it wouldn't be equally visible to
> prose and plain links.

A tool that encourages or even just allows authors to define somethign as
equivalent makes that just as visbile as a text editor does. Perhaps even
more so, because such a tool can do that through more user-friendly
terminology than HTML can.

>> I can't follow. I'm not talking about browsers being smart. I'm
>> talking about
>> users making decisions that suit them best.
>
> I thought above you were talking about browsers making decisions for
> users by default and the users having a recourse to correct these
> choices.

Yes. I didn't think to label that is "smart" though. In my mind that means
the user decides. He just delegates the most boring/repetitious
decision-making to a tool (while retaining the optionto override).

Perhaps that is "smart", yes. I agree that it takes more smartness to have a
UA reasonably succesfully decide on which equivalent the user probably wants,
than for it to leave that entirely up to the user. But then the user needs to
do the work; can't delegate.

So in itself I see such "smartness" is plainoviously useful. The question
cerainly is whether it can be implemented so reliably that it in fact *is*
useful. But again, that question should come after the establishing of user
needs.

>> [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.)
>
> If software were smart enough to figure out whether explicit
> assertions are lies, why bother with making explicit assertions in
> the first place instead of letting the software do its smart thing?

I understood you to say that current search engine technology is smart enough
to index prose, ignoring markup. If that's the case, then I don't see why it
couldn't compare its indexed prose with the content of explicit 'invisible'
metadata.


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

Received on Friday, 3 August 2007 21:01:57 UTC