putting a link on a logo

D

David Dorward

mbstevens said:
* It is a bad idea to try to guess an author's intention.
Authors can intend a huge range of things.
Their bosses can intend a huge range of things.

Who is trying to guess an author's intention? We're discussing the general
case of a webpage where the primary purpose is not to describe the logo,
but where a logo is used to indicate the publisher of the page.
* The title of a logo is not necessarily "logo".

Alan suggested that it could be used to provide the optional additional
information. The title attribute is for "advisory information" not an
actual title.
* It _is_ a good idea to try to guess what a visitor will want
from a page. But an author should allow for a wide range
of visitors. I explained to David why some blind persons
might like to have the information that what they are 'looking'
at is a logo.

As previously mentioned, the longdesc attribute provides a good method for
conveying a description of what an image looks like.

Also, the author should consider the primary purpose of a page and avoid
cluttering it up with large amounts of information that is irrelevant to
the majority of people who will see it. If you're helping 1% of users while
harming 99% then the trade off isn't very good.
 
M

mbstevens

Who is trying to guess an author's intention? We're discussing the general
case of a webpage where the primary purpose is not to describe the logo,
but where a logo is used to indicate the publisher of the page.

I thought we were discussing the best way to mark up a logo image.

Period.

The additional stuff about 'primary purpose is not to describe..."
is assuming your own conclusion in one of the premises.
Alan suggested that it could be used to provide the optional additional
information. The title attribute is for "advisory information" not an
actual title.

That's fine, but it is still up to me as web author exactly what purposes
I have for a particular bit of text.
Also, the author should consider the primary purpose of a page

....bearing in mind that the author and his boss determine what
that purpose is.
and avoid
cluttering it up with large amounts of information that is irrelevant to
the majority of people who will see it. If you're helping 1% of users while
harming 99% then the trade off isn't very good.

Web statistics! ...... don't get me started.
You also have to take into account how much actual 'harm' will
come to those who are forced to look at an extra word and happen not
to be interested in it. It is surely not a simple algorithm, and the
statistics are just not there.
 
D

David Dorward

mbstevens wrote:
I thought we were discussing the best way to mark up a logo image.

Period.

We weren't. said:
Web statistics!

No, those weren't statistics. You note the word "if"?
You also have to take into account how much actual 'harm' will
come to those who are forced to look at an extra word

listen to an extra couple of sentences ... on every page ...
 
A

Alan J. Flavell

* It is a bad idea to try to guess an author's intention.

Indeed. That's why I'm trying to avoid it. Instead, I'm trying to
help to inform authors about the stated purposes of various
attributes, guidelines to their use, and to show them some samples of
where it went horribly wrong (my alt text howlers collection), and
invite them to apply the principles in such a way that they accord
with *their* intentions.
Authors can intend a huge range of things.

They can still apply some principles and guidelines in accomplishing
their intentions.
Their bosses can intend a huge range of things.

Their bosses rarely seem to understand how the web works. if their
monkeys do exactly what they are told by their bosses, instead of
interpreting the demands in the framework of the web, they may very
well find their intending could well blow a raspberry in their general
direction...
* The title of a logo is not necessarily "logo".

I sense the development of a number of SMAs. That was one of them.
* It _is_ a good idea to try to guess what a visitor will want
from a page.

Sure: but since their wants can be so diverse, and often enough
mutually contradictory, that needs to be handled with care. That's
one of the reasons for having explanatory stuff in the HTML
specification, and accessibility guidelines.
But an author should allow for a wide range of visitors.

I don't see anyone around here claiming that they shouldn't.
I explained to David why some blind persons
might like to have the information that what they are 'looking'
at is a logo.

I once read a detailed rant from a blind contributor, whose
contribution to the discussion was that a web page was axiomatically a
visual experience, and he demanded to have every tiny visual detail
described and explained to him.

Since every different browser/version, and even screen size and
"resolution" setting, will show a page differently in one way or
another, I have no idea how to fullfil his demand.

Other blind contributors opined that what a web page contained was
foremost *content*, which they wanted to access, and they sure didn't
want to be pestered by descriptions of visual clutter, such as
alt"small red bullet", nor variants on alt="our logo", with or without
a statement of whose logo it was and/or what it looked like.

You have three attributes of the img tag at your mercy for offering
these various items. I say use them according to the guidelines, so
that a fair range of users' wishes can be accommodated without
upsetting those whose demands are different.
 
M

mbstevens

You have three attributes of the img tag at your mercy for offering
these various items. I say use them according to the guidelines, so
that a fair range of users' wishes can be accommodated without
upsetting those whose demands are different.

And I agree with all that.
URL of the guidelines you are using?
(I'm gone for a while.)
 
D

dorayme

mbstevens said:
Certainly does, but in the absence of more information about
what his business or lack thereof is, 'logo' was about the best
I could come up with.

You took the words out of my mouth...
 
D

dorayme

"Alan J. Flavell said:
[...] in the absence of more information about
what his business or lack thereof is, 'logo' was about the best
I could come up with.

alt="Foo corporation" (if the name of the corporation isn't already
there in text alongside), or alt="" if it isn't. Works for any
unspecified corporation, and it's obvious how to adapt it.

alt="logo" is almost certainly wrong, and sets others a bad model to
work from.

I read it as a place holder for something more descriptive, as
such it is not anywhere near wrong. As for this being misleading
.... well now... what isn't misleading about any ng posts to
various folk.
 
M

mbstevens

I read it as a place holder for something more descriptive, as
such it is not anywhere near wrong. As for this being misleading
... well now... what isn't misleading about any ng posts to
various folk.

Indeed, thank you. Who was not introduced to the venerable "x" and "y"
before their first algebra course? If I were writing to so blunt an
audience I would want to be working for daytime t.v.,
at least getting paid for it.
 
J

Jim Higson

David said:
If I'm trying to find out about the new Rocket Skates from Acme Inc then
I'd want to know that I was looking at Acme Inc's website - but why would
I care that it was a logo conveying that information?

Maybe in this case, since the alt text can't contain elements and ACME is an
acronym (actually probably a backronym, but there isn't a tag for that),
the most semantic markup would be:

<a href="/">
<object type="image/png" data="images/logo">
<acronym title="A Company that Makes Everything">
ACME
</acronym>
</object>
</a>

No idea if this would work as expected. Probably IE would get it wrong.
 
A

Alan J. Flavell

And I agree with all that. URL of the guidelines you are using?

Well, that's a hard one for me. The guidelines that I try to follow
are chiefly in my head: but I reckon confidently that they accord with
the definitions in the HTML specifications, and with the letter and
the intention of the WAI Content guidelines (version 1, at least), as
well as being in good accordance with the stated needs and
requirements of quite a number of blind users (except a few cases
which are mutually contradictory, and really could not be both
fullfilled).

By the way, there is a certain dependence on client agents providing
support for the techniques used. But HTML4 has been on the record for
nearly a decade: for those who need longdesc, it would surely not be
too much to ask for then to select a browser which supported it?

So now where do we go. If I take the trouble to try to set down the
principles and guidelines as I understand them, it'd be a rich source
for the inveterate nit-pickers, who are always keen to miss the
underlying principles if at all possible by chiselleling away at any
possible nit - often enough nits that they themselves created, for no
other reason than to shoot them down.

But I guess I could do it.

Most of my web-published materials in this area, as you may know, are
getting a bit curled at the edges, since they concentrate so strongly
on the alt attribute (which was all that was available at the time it
was started), and only mention title= and longdesc= in passing,
really. http://ppewww.ph.gla.ac.uk/~flavell/alt/ and especially
http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html

Whatever you may think about Hixie's views on this and that, it's
certainly worth reading his article, and thinking about what it means.
http://www.hixie.ch/advocacy/alttext

Jukka Korpela has some materials on the topic, as google has no
difficulty in pointing out. As usual, what is there is well
researched. But, like mine, it seemed to concentrate more on the alt=
attribute than the other matters.

So, where do we go from here?
 
J

Jukka K. Korpela

Alan J. Flavell said:
But HTML4 has been on the record for
nearly a decade: for those who need longdesc, it would surely not be
too much to ask for then to select a browser which supported it?

I'm afraid it would.

Support to longdesc is virtually nonexistent in mainstream browsers, and why
would a user switch to a special browser just because he wants to check the
long description of an image? Actually most users probably have no idea of
the longdesc attribute, and extremely few pages use it, so I don't think
users _should_ know about it.

The alt attribute is sufficient for most images. If an image needs a long
description, then it should be provided using normal methods, as text on the
page near the image or on a page linked to from there, using a normal link.
That's simple, that's understandable, and it works across browsers.

The longdesc attribute is just too poorly supported and too implicit for
anything serious. I would go as far as saying the same about the title
attribute, but you might not follow me there.

The only reason why it could make sense to _hide_ the reference to a long
description is that we might think that the long description is only for
those who cannot see the image and would therefore see or hear the reference
instead. But that's not how browsers work, and that's not how they are
required to work. Besides, even if the longdesc attribute worked
technically, how could we know that the long description does not benefit
people who _do_ see the image but just don't understand it?

The longdesc attribute could be relied on only if it were universally
supported and users were always made aware of the presence of a description.
But that would be rather close to putting a link near the image, wouldn't
it? And that's what we can do, here and now; we can even select and position
the link text.

There's one more reason not to tell authors to use longdesc. In addition to
being practically useless, it complicates things. It's a new concept to be
learned, remembered, and applied. It's an unnecessary complication in a
world where most authors still don't understand even the simple principle
behind the alt attribute.
 
A

Alan J. Flavell

I'm afraid it would.

Sorry, I maybe did not make my sarcasm clear enough at that point.
Support to longdesc is virtually nonexistent in mainstream browsers,
and why would a user switch to a special browser just because he
wants to check the long description of an image?

I fully agree.
Actually most users probably have no idea of the longdesc attribute,
and extremely few pages use it, so I don't think users _should_ know
about it.

This is a self-fulfilling statement. If no-one uses it, there's no
point in implementing it. That's sort-of true. If no browser
implements it, there's no point in using it? Well, no, not exactly.
Using it does no harm to anybody, and may occasionally stimulate some
action on the browser side, such as implementation in the browser, or
a plug-in, or a bookmarklet etc. etc.
The alt attribute is sufficient for most images. If an image needs a
long description, then it should be provided using normal methods,
as text on the page near the image or on a page linked to from
there, using a normal link. That's simple, that's understandable,
and it works across browsers.

There's probably a wide range of situations where that procedure
would be appropriate. In any case, it's arguable that for web
browsers it's better to use <object> instead of <img>, with a graceful
fallback for the browser-like OS component.
http://ppewww.ph.gla.ac.uk/~flavell/www/obj-for-img.html

That brief sketch doesn't go into detail about how one would
produce the counterpart of longdesc (it wasn't really composed for
that purpose), but I think it should be reasonably obvious.
The longdesc attribute is just too poorly supported and too implicit
for anything serious. I would go as far as saying the same about the
title attribute, but you might not follow me there.

If I ever get to write this page I was talking about, I would
certainly cover the browser difficulties with longdesc. Oh, right, I
do disagree with you about title= - browser implementations for title=
aren't ideal, but at least they are there. And also, title="" is a
handy workaround, if no title is wanted, for MesSIE's habit of
popping-up alt texts at inappropriate moments.
The only reason why it could make sense to _hide_ the reference to a
long description is that we might think that the long description is
only for those who cannot see the image and would therefore see or
hear the reference instead. But that's not how browsers work, and
that's not how they are required to work. Besides, even if the
longdesc attribute worked technically, how could we know that the
long description does not benefit people who _do_ see the image but
just don't understand it?

Those are all fair comments, indeed.
There's one more reason not to tell authors to use longdesc. In
addition to being practically useless, it complicates things. It's a
new concept to be learned, remembered, and applied. It's an
unnecessary complication in a world where most authors still don't
understand even the simple principle behind the alt attribute.

I can see what you're getting at, but in general I think you're being
unduly pessimistic. While most of the world seems to be beavering
away with some grand-scale experiment of finding just how many faults
they can get into a web page without it obviously breaking in their
supposed mainstream viewing situation, there's still a hardcore of
folks who are trying - and even succeeding - in doing a proper job,
producing pages which behave with reasonable grace and comfort in a
wide range of browsing situations.

So much for the general. As you say, longdesc is a specific problem.
But I wouln't be trying to base the argument on not using longdesc, on
the fact that most alt texts seem inept. Yes, I know that even the WAI
keep getting it wrong, and keep switching from "textual alternative
for the purpose of the image" (good) to "description of the purpose of
the image" (usually wrong).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,535
Members
45,007
Latest member
obedient dusk

Latest Threads

Top