Re: Distinguishing different aspects of accessibility

At 12:17 +0300 UTC, on 2007-08-06, Henri Sivonen wrote:

> On Aug 4, 2007, at 00:00, Sander Tekelenburg wrote:

[... optionally not present audio equivalents to deaf users]

> Perhaps this should be approached by finding out the actual user
> needs are through observational user testing to see which choices
> presented to users actually cause badness by, for example, slowing
> users down.

Actual research results would definitely be interesting, yes. But when we
talk about the possibility to hide equivalents, it doesn't seem all that
essential to me, given that it seems extremely likely that the majority of
authors and users want to have only one equivalent (the 'main' one) be
presented by default. If there is agreement on that need, we don't need to
know if it also applies to certain minorities.

[...]

>> Note that I'm think of a general indicator here.
>
> On the page-level as in the feed case or local to the rendering of
> the part of content that has a hidden (except for the indicator)
> alternative?

I suspect it would have to be "local", as you call it. A toolbar indicating
that there are equivalents available for some object in the <body> would not
be useful, as it would probably be impossible to be clear about which item in
the <body> it refers to.

>> 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.]
>
> FWIW, I think a cursor change on hover is a rather awful indicator in
> terms of discoverability. It requires the user to scan the page with
> a cursor to find out if alternatives exist.

Agreed. That's why I said "not ideal".

Note however that it might very well be ideal for some users. Those who
generally need or just want to have a clear indicator would need something
better. But those who generally prefer to simply consume the 'main'
equivalent would probably not want a more 'agressive' indicator at all.

[...]

>> 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.
>
> Wouldn't that involve asking the user to order a list of known file
> formats to an order of preference? Seems like a task one wouldn't
> want to put forward to J. Random User.

No, "asking" == bothering the user. I said "be allowed".

Being allowed to change such settings is nothing new. Most UAs (or host OS)
allow users to configure how a resource with a certain MIME type should be
treated. They'r not asked to do so, and thus not bothered with it. UAs ship
with reasonable defaults that most users don't need to change. But they are
allowed to make changes, and those who need to do. (Even that can be
relatively user-friendly in certain cases. A plug-in installer might be
allowed to register itself as teh default for a certain MIME type, for
example.)

So it seems to me that [1] a default and [2] allowing users to change that is
not without precendence for the sort of thing we're talking about.

>>> 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?
>
> For the purpose of guessing if something has been "lost in
> translation", yes.

Well, the proposed <alt> would seem to allow for it, I guess.

>>> 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>
[...]

See <alt> thread, starting at
<http://www.w3.org/mid/20070804012329.GA6301@jdc.local>.

[...]

> Quite a few users know what PDF and PowerPoint are. For those who
> don't, how would "animated presentation" and "pretty text with
> images" allow them to make an informed choice?

In the much the same way that, "coffee" and "milk" does. Most users in most
situations do not need to know exactly what type of coffee or milk they're
consuming. Having to choose from types of beans without knowing they're
coffee would provide problems for most users. Only when for example they know
to prefer a particlar type, or they know to be allergic for one, do they need
to know.

Translated to the Web: when the browsing environment can handle PDF, there is
no need for Joe Average to know what PDF is. Knowing it would be helpful, but
having to know it would be limiting.

[...]

> I have rather serious doubts about the UI feasibility of such
> configuration, because it isn't just about PowerPoint vs. PDF but
> about various file format juxtapositions in various contexts
> depending on whether the user is seeking a read-only file or
> something to remix.

Could you give examples of different contexts in which users would likely
want different defaults?

[... 'visibility of metadata' to authors]

> Making invisible metadata visible would involve a novel visualization

The idea of <alt> is visible equivalents made invisble. See <alt> thread,
starting at <http://www.w3.org/mid/20070804012329.GA6301@jdc.local>.

> (in visual editors)

What's a "visual editor"?

> and would necessarily be against WYSIWYG if the data being
> visualized is invisible in a usual visual browser.

"WYSIWYG" contradicts the Web per definition. I recognise the reality that
some users will continue to be fooled into thinking otherwise, but let's not
downgrade reality to cater for that. In other words, let's not make it
needlessly difficult to produce high quality web content just because that is
impossible to do with a 'WYSIWYG editor'.

[... parties capable of indexiing non-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.
>
> Would there be any case where if the comparison resulted in a
> "invisible metadata disagrees" result, the search engine would want
> to use invisible metadata nonetheless?

Use, yes. Nonetheless, no. What I'm saying is that from the discrepancy
between visible and invisable data, it could be deduced that the author is
abusing the 'invisible' data to lie. Based on that, the resource's search
result rank could be lowered


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

Received on Monday, 6 August 2007 11:43:59 UTC