LONGDESC files

[Jukka K. Korpela]

Re: LONGDESC files

Tim <admin@sheerhel l.lan> wrote:
[color=blue]
> Using normal typing brackets (thus) is probably better than square
> brackets.[/color]

I don't think so, because alt="(...)" makes perfect sense when "..." is
a genuine replacement for an image, conveying the same message as the
image instead of just naming the image. The parentheses would just
indicate the text as, well, parenthetic.
[color=blue]
> It should stand a better chance of being read out in a
> less intrusive manner[/color]

That's the _problem_ with it. The user would not distinguish between
the renderings of
(foo bar)
and
<img src="..." alt="(foo bar)">
and would have little way of guessing what's going on.

But now that I think of it, maybe alt="photo of..." or alt="image
of..." or something like that is sufficient, and should be less
intrusive. That is, _if_ there is no alt text that could adequately
_replace_ the image, then using an alt text formulation that explicitly
uses a word like "image" or "photo" is suitable.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Jukka K. Korpela]

Re: LONGDESC files

"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue]
> I was really responding to the view "So there you have the basic
> text, where you then provide graphic alternatives to some text,
> namely the actual photos".[/color]

That statement of mine was meant to be provocative, though mainly as
regards to provoking thoughts. :-)
[color=blue]
> But for my photograph pages, the
> photographs are primary and the text is subsidiary.[/color]

Certainly. But design-wise, and to people who cannot see the images,
the texts rather than the images are the solid basis. You could design
and implement the page well before having uploaded (or selected, or
even _taken_!) the actual images.

That way, the page will work in no-images mode from the very start, and
search engines could index it early, and people could see what has been
planned to appear there. Of course, if images have caption texts (as I
think they should in most photo galleries), then these texts will
largely duplicate the alt texts - and one might even say that in such
cases you could use alt="", but it's probably clearer to use
"redundant" alt texts that duplicate the caption (often in an abridged
form).

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Barry Pearson]

Re: LONGDESC files

Jukka K. Korpela wrote:[color=blue]
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:[/color]
[snip][color=blue][color=green]
>> But for my photograph pages, the
>> photographs are primary and the text is subsidiary.[/color]
>
> Certainly. But design-wise, and to people who cannot see the images,
> the texts rather than the images are the solid basis. You could design
> and implement the page well before having uploaded (or selected, or
> even _taken_!) the actual images.[/color]
[snip]

I believe proper design only makes sense in the context of a target audience.
Otherwise, you can't select from alternative methods, or evaluate whether the
design has met its objectives.

And the target audience for my photographs are sighted people. It sounds
harsh, but really that is the nature of photography. They are also people
prepared to wait while a 100 KB image is downloaded. And then have a
large-enough viewport. Rather than spend extra time trying to reach people
outside that group, I am better off producing more content for that group.

These characteristics appear to break a number of the guidelines about
developing web pages. But I believe too many of those guidelines are presented
as though they apply generally. Some guidelines appear to assume that the web
is about text, for example. Perhaps in most cases - but certainly not all. In
fact, there are various "communitie s" on the web, sometimes "implicit
communities", who can be perfectly happy ignoring those guidelines, and
perhaps have different guidelines. Not for everything they ever do - just when
they are pursuing a particular activity. I have different design criteria &
guidelines for different web sites. This is just "marketing" - the need for
that hasn't gone away.

(I don't take photographs specifically for the web. I take them mainly to be
projected, perhaps 150cm x 150cm, or printed, perhaps A3 or larger).

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Jukka K. Korpela]

Re: LONGDESC files

"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue]
> And the target audience for my photographs are sighted people. It
> sounds harsh, but really that is the nature of photography.[/color]

It's not harsh at all. But these sighted people might be using a text-
only browser, or a speech browser, or a graphic browser configured not
to show images, or a search engine. Or a blind person might stumble
across your page, hears that you have a photograph of
/Cryptavis rarissima/, and remembers that this is just the species that
a friend of his has been extremely interested in.

Of course, using _either_ image caption texts (as normal textual
content) _or_ alt attributes will help in each case. But as mentioned,
it's best to use both.

But the principle of designing first a text-based version also helps in
making the content appear in an order that is suitable for linear
consumption and making things verbally explicit. For example, if all
the images are photos of birds of a specific genus, it might seem
redundant to mention this, since the user can see that at a glance. But
if you think about textual access, it suddenly makes quite some sense
to include a descriptive heading and perhaps a short explanatory
paragraph.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Harlan Messinger]

Re: LONGDESC files


"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message
news:Xns9447F20 B3E00jkorpelacs tutfi@193.229.0 .31...[color=blue]
> "Harlan Messinger" <h.messinger@co mcast.net> wrote:
>[color=green][color=darkred]
> >> <p><img alt="Y" src="Y.gif">ucc a said that...</p> intended to
> >> create a decorative initial.[/color]
> >
> > *This* strikes me as a hack that shouldn't be expected to work,[/color]
>
> It should work and it does work. Not optimally e.g. on IE in no-images
> mode, but otherwise pretty well.
>[color=green]
> > with the "Y" treated not only in the flow, but *as part of the word
> > to which it is adjacent*.[/color]
>
> Of course. It's similar to
> <p><font style="initial" >Y</font>ucca said that...</p>
>[color=green]
> > If you want drop-caps, wait until browsers
> > implement the CSS standard that supports them.[/color]
>
> Whether you like the idea or not, it is valid markup with well-defined
> meaning. Besides, the use of highly decorative initials is hundreds of
> years old (you remember the old printed books with hand-painted
> initials?), and if someone wants to imitate that, he will be suggesting
> an image to replace a letter.[/color]

<chuckle> I realize all of you here aren't the same person, so this response
isn't personal, but your comment is ironic given that this is the newsgroup
where a bunch of people have berated me for defending the carrying over of
effective, time-honored graphical techniques into web publishing.

The prevailing philosophy here has been to avoid the use of HTML for
formatting or layout. No <font>s, use <em> instead of <i> and <strong>
instead of <bold>, and then use CSS or let the browser do what it wants.
From that perspective, I'd expect that using an <img> tag to insert a
depiction of a letter as a literal part of the text would be anathema.

[Harlan Messinger]

Re: LONGDESC files


"Alan J. Flavell" <flavell@ph.gla .ac.uk> wrote in message
news:Pine.LNX.4 .53.03120422370 01.24336@ppepc5 6.ph.gla.ac.uk. ..[color=blue]
> On Thu, 4 Dec 2003, Harlan Messinger wrote:
>[color=green]
> > "Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message[color=darkred]
> > > common constructs like
> > > <p><img alt="Y" src="Y.gif">ucc a said that...</p>
> > > intended to create a decorative initial.[/color]
> >
> > *This* strikes me as a hack that shouldn't be expected to work,[/color]
>
> I wouldn't encourage its use except in specialised circumstances; but
> the idea has surely been familiar since the early days of the Netscape
> corp, when everyone and his dog was putting notices about their site
> being <img src="Nlogo.gif" >etscape-enhanced.[/color]

Until now the exhortations I've been seeing here have been to follow "proper
practice", which in general means NOT to do what old Netscape did. It's
strange to see Netscape used now as even a mild justification.

[snip][color=blue]
>[color=green][color=darkred]
> > > page. I have suggested the convention of putting an alt text into
> > > brackets when it is actually just a description and not a replacement,
> > > e.g. alt="[my horses], as opposite to alt="I have three horses."[/color]
> >
> > For a speech synthesizer, that's no help.[/color]
>
> I don't grasp your meaning. Now sure - by default when IBM HPR was
> presented with that, it bawled out LEFT SQUARE BRACKET etc. in a very
> intrusive way, but it can be taught to do what the user wants, and the
> convention mentioned by Jukka is indeed a long-standing one on the
> WWW. Sometimes it can be better to follow an accepted convention even
> if you wouldn't have chosen it as your own preference.[/color]

It seems inconsistent to me that it would be intrusive for a reader to give
some indication that an image was being processed, but that it would
actually speak brackets included directly in the text.

I'm rapidly reaching the conclusion that it's impossible to tell what a
non-image-displaying browser is going to do, and that the concept of a
"correct" thing to do with alt text is a wild goose. For one thing, I don't
think there's any general way to come up with alt text that will work
optimally in both text browsers AND speech browsers.
[color=blue]
>[color=green]
> > As for text browsers, I don't see how it makes things any clearer,
> > since the user has no way to know that the brackets represent an alt
> > attribute rather than actual brackets in the text.[/color]
>
> Nor indeed that the vertical bars inserted by some text browsers for
> tabular data are not present in the original text. Be reasonable:
> these kinds of text browsers only have character cells to play with,
> they can't display anything that isn't a text character. It comes
> with the territory; they have to work with the materials to hand.
>[/color]

[Harlan Messinger]

Re: LONGDESC files


"Tim" <admin@sheerhel l.lan> wrote in message
news:db50tv4aes 3smvusm0dd73hqe uv1i980ai@4ax.c om...[color=blue]
> "Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote
>[color=green][color=darkred]
> >> Seriously, I may have misformulated my point. What I meant was
> >> primarily related to the problem of adjacent <img> elements and whether
> >> their alt texts should be considered as adjacent too. I still think
> >> they should. Otherwise there would be quite unnecessary problems with
> >> common constructs like
> >> <p><img alt="Y" src="Y.gif">ucc a said that...</p>
> >> intended to create a decorative initial.[/color][/color]
>
> I'd expect the image, or the alternative text, to be in the same place
> that the <img> element is, so long as you've not done something else to
> reposition the image (e.g. floated it to the right, or added padding).
> Just the same as we'd expect any other properly placed HTML element to
> be where it's place in the source, relative to what comes before and
> after it; taking the usual white space rules into account.
>
>
> "Harlan Messinger" <h.messinger@co mcast.net> wrote:
>[color=green]
> > *This* strikes me as a hack that shouldn't be expected to work, with the[/color][/color]
"Y"[color=blue][color=green]
> > treated not only in the flow, but *as part of the word to which it is
> > adjacent*.[/color]
>
> Why, though? Images are inline objects;[/color]

This word is being overloaded here, in the object-oriented programming
sense. "Inline" in HTML means "as opposed to block". But (sorry to keep
harping on this analogy) unless you're building a rebus, images are not
textually "inline" with the text they accompany, and it only confuses the
user to treat them as such. If the standard says, "Treat them as such", then
the standard is responsible for the confusion.
[color=blue]
> they can be in-line with some
> text, it has an alternative, and there's no significant white space
> either side of the image, either.
>
> I wouldn't call it a hack, it's doing precisely what the specifications
> allow.[/color]

The two aren't contradictory.
[color=blue]
> Whether it's a brilliant idea, or not, is another matter. Then
> you're into the realms of opinion.[/color]