Re: Distinguishing different aspects of accessibility

On Aug 6, 2007, at 14:34, Sander Tekelenburg wrote:

> At 12:17 +0300 UTC, on 2007-08-06, Henri Sivonen wrote:
>
>> 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.

If this WG is to ask that UA vendors devote a non-trivial amount of  
engineering resources to develop presentation and configuration for  
features that selectively pick one alternative and suppress others  
and then ask authors to make an effort to write for these features,  
there had better be good rationale why this is Solving Real Problems.

In particular, it may entirely possible that suppressing alternatives  
is Solving Real Problems in some cases but not Solving Real Problems  
in other cases. Instead of designing one unified consistent  
architecture for all alternatives, we should only figure out what the  
cases of Solving Real Problems are and address those. (For example, I  
suspect that accessibility for the blind and the deaf don't  
necessitate symmetric solutions, because the role of visual and aural  
content on the Web is not symmetric and the random access properties  
of aural and visual presentations are not symmetric.)

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

That's not enough. It should also be established that the badness of  
being offered more than one alternative is so serious that  
eradicating this badness is worth all the effort in spec writing, UA  
engineering, authoring and UA configuration.

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

To me that thread looks like debating solution before answering:
  1) What the problem is?
  2) Is the problem so serious that the status quo is not good *enough*?

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

While GIF and PNG or MPEG-4 and Ogg could be seen as different  
flavors of coffee, PowerPoint and PDF aren't just different types of  
milk.

>> 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?

If the user wants to only view the document, it makes sense to  
download the PDF file. If he wants to edit the presentation, it makes  
sense to download PPT.

I already gave the example of tradeoff with font breakage vs.  
animations.

>> (in visual editors)
>
> What's a "visual editor"?

An editor that presents the document (not source code) visually to  
the user for editing.

> "WYSIWYG" contradicts the Web per definition.

Well, a non-trivial number of authors uses authoring tools that  
contradict the Web...

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

Here's another point of view:
The W3C sometimes gets accused of not considering authoring tools in  
spec development. Not "downgrading" to take into account authoring  
tool reality doesn't seem like a productive way to approach this  
issue. Instead of leaving it to authoring tool vendors to innovate  
later, it would be good to make sure that features that need  
authoring tool support are designed with a least one plausible way of  
exposing them in GUI authoring tools.

> 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

It seems to me that with a policy like that, invisible metadata would  
only be a liability and authors would be better off omitting it.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 6 August 2007 13:10:57 UTC