- From: Sander Tekelenburg <st@isoc.nl>
- Date: Fri, 3 Aug 2007 23:00:42 +0200
- To: public-html@w3.org
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