"title" versus "alt" text for thumbnails
Barry Pearson
the common way. I currently use "alt" text in the thumbnail "img" tags to
describe the subject of the photograph. I'm pretty sure that is wrong.
I want to use the "best" combination of "title" and "alt" attributes. I want
the "logical best" - conforming to the spirit of their purpose. And the
"practical best" - working with all common browsers and readers. I use IE6,
which is not representative, so I can't experiment and judge what all other
browsers and readers will do.
Here are my thoughts, which I would like validated/refuted, please.
I want "tooltips" so that sighted-people know what the target photograph will
be. For example, I want to tell them they will see a photograph of a "Sally
Lightfoot Crab". I understand that I should use "title", not "alt", for
tooltips. Do all common browsers and readers make use of "title"? What would a
visually-impaired person get?
If the thumbnail image isn't visible for any reason, there appears to be
little point in describing it. (In that case, only the target page is
important). But I realise I need to supply "alt" text for it. What makes most
sense? I am tempted to say alt="" because if you can't see the thumbnail it is
little more than a spacer.
There are 3 places (at least) where I could put the "title". In the "td" tag
(I still use tables for this purpose), in the "a" tag, or in the "img" tag. In
IE6 only the latter works properly as a tooltip in the case of thumbnails, so
I will put it there. But should I put it elsewhere as well? (I suspect that
will cause readers to duplicate the information).
My thought is to supply just the raw information in the "title" about the
target photograph, such as "Sally Lightfoot Crab, Grapsus grapsus", and not
put "Link to ..." or "Photograph of ..." in front of this. The latter may be
useful to distinguish between a photograph page and a text page. But isn't
this patronising in a photograph gallery where that should be obvious?
A further query is whether thumbnails work at all for readers? If not, since I
don't want to add text links to the thumbnail galleries, do I need to provide
a separate set of pages to be used by readers? I want to avoid that because of
the extra work - these are non-commercial (hobby) sites.
Thank you.
I found the following relevant, although it was answering someone else's
query:
http://groups.google.com/groups?as_umsgid=Pine.LNX.4.40.020506...@lxplus033.cern.ch
But much of the material on the web appears to pre-date exploitation of
"title", and doesn't have appear to have crystallised into clear guidelines.
--
Barry Pearson
http://www.Barry.Pearson.name/photography/
King Queen
<ne...@childsupportanalysis.co.uk> wrote:
<lots of interesting questions about TITLE and ALT attributes for
images>
I don't know the answers to your questions, but they are questions I
have been thinking about for some time. I hope somebody with more
knowledge can reply.
But also you've forgotten the use of "longdesc" or "D-links". A
longdesc is used as an attribute in the IMG tag and links to a very
simple HTML file which should contain a description of the image for
blind people. I know you say the image is of little consequence if you
can't see it - but still I think it's polite to put the description in
and then blind readers can make the choice themselves. The idea being
that you can put a longer, pictorial description in a longdesc than
you can in alt or title tags.
As for tooltips: IE incorrectly shows ALT text as tooltips, as you're
probably aware. I don't know what puts tooltips in Opera - seems no
rhyme or reason, because when I use TITLE attributes they don't seem
to do anything tooltip wise (similarly with ALT) but when other people
do it does seem to work like that.
Thumbnails do work for most readers. I always put "Photo: blah" or
whatever in the ALT text, and make sure it says "click to go to
enlargement" or something, to make absolutely clear it's a link to
speech browsers etc.
Doug
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"Those who profit from such systems (of domination) will not readily
yield to new, more just social organisation of human life within the
biosphere." R. R. Ruether
Jim Ley
<kq.larts...@kingqueen.org.uk> wrote:
>But also you've forgotten the use of "longdesc" or "D-links". A
>longdesc is used as an attribute in the IMG tag and links to a very
>simple HTML file which should contain a description of the image for
>blind people.
Not quite, a Long Description isn't required to be HTML, it could be
any format (probably most practical if it is HTML though, but SVG may
certainly be more useful a format for describing an image.) It also
isn't just for blind people, anyone wanting a long description would
find it useful - you should certainly include the image for example.
>As for tooltips: IE incorrectly shows ALT text as tooltips, as you're
>probably aware.
Oops... no it doesn't, well it does do it, but it's certainly not
incorrect - you can't really claim any rendering of HTML content is
incorrect since HTML defines no rendering.
Jim.
Chris Morris
> But also you've forgotten the use of "longdesc" or "D-links". A
> longdesc is used as an attribute in the IMG tag and links to a very
> simple HTML file which should contain a description of the image for
> blind people. I know you say the image is of little consequence if you
> can't see it - but still I think it's polite to put the description in
> and then blind readers can make the choice themselves. The idea being
> that you can put a longer, pictorial description in a longdesc than
> you can in alt or title tags.
Longdesc I'm never entirely sure about. Support for it isn't
particularly good at the moment, so while it's useful for supplemental
information the alt attribute needs to be good enough anyway.
Given the poor support, where it's necessary a normal <a href> link
afterwards seems the better option, which makes longdesc redundant.
<img src="photo.jpg" alt="..."> <a href="longdesc.html">More
information about ...</a>
or
<img src="photo.jpg" alt="Photo:"><a href="longdesc.html">Ducks in the
pond</a> CSS-styled so that the <a> is a caption for the image where
appropriate.
or similar. I don't think <a href="...">D</a> is anything like widely
used enough to be a recognised convention.
> Thumbnails do work for most readers. I always put "Photo: blah" or
> whatever in the ALT text, and make sure it says "click to go to
> enlargement" or something, to make absolutely clear it's a link to
> speech browsers etc.
In what way does 'click to go to enlargement' make it clear it's a
link to speech browsers, which, by and large, don't have mice?
And since most speech browsers already indicate a link by fairly clear
means (they prefix 'LINK' or change voice, most of the ones I've
tried) it's already clear enough that it is a link.
<a href="..."><img src="..." alt="Photo: ..."></a> should be clear
enough.
--
Chris
Barry Pearson
> On Fri, 29 Aug 2003 09:43:42 +0100, "Barry Pearson"
> <ne...@childsupportanalysis.co.uk> wrote:
>
> <lots of interesting questions about TITLE and ALT attributes for
> images>
> But also you've forgotten the use of "longdesc" or "D-links". A
> longdesc is used as an attribute in the IMG tag and links to a very
> simple HTML file which should contain a description of the image for
> blind people. I know you say the image is of little consequence if you
> can't see it - but still I think it's polite to put the description in
> and then blind readers can make the choice themselves. The idea being
> that you can put a longer, pictorial description in a longdesc than
> you can in alt or title tags.
Thanks for that. I had forgotten about "longdesc", never having used it.
I probably didn't make it clear that I was only talking about the thumbnail
gallery page. A thumbnail is really just a button, although it gives
additional clues to a sighted-person. I give additional information, in the
target page, about the photograph. For example, if it is "Sally Lightfoot
Crab, Grapsus grapsus", that appears as the "alt" text for the image, and in
the page's "title" tag, as well as in the text below the photograph.
I'll investigate whether to use "longdesc" as well. I am wary of going OTT and
creating too much repetition. If I have a photograph of a Pelican, should the
"longdesc" describe that specific photograph ("Pelican flapping its wings"),
or would a link to a fact sheet on Pelicans be better (which I could then use
for all Pelican photographs)?
[snip]
> Thumbnails do work for most readers. I always put "Photo: blah" or
> whatever in the ALT text, and make sure it says "click to go to
> enlargement" or something, to make absolutely clear it's a link to
> speech browsers etc.
I have read that people using such browsers know enough about what is going on
not to need lots of explanation. But I don't know whether they need anything
at all. If they already know from the context that it is a link, then there is
no need to repeat it. But if it is just another bit of text that gets spoken
by the reader, then they may need a clue that it is a link.
Thumbnail galleries are so common that I expected to find specific
accessibility guidelines for them on the web. I'm sure they are there, but I
haven't spotted them yet.
Tricky stuff! I bet most people get it wrong, as I've done.
Barry Pearson
> On Fri, 29 Aug 2003 11:02:26 +0100, King Queen
> <kq.larts...@kingqueen.org.uk> wrote:
>
> >But also you've forgotten the use of "longdesc" or "D-links". A
> >longdesc is used as an attribute in the IMG tag and links to a very
> >simple HTML file which should contain a description of the image for
> >blind people.
>
> Not quite, a Long Description isn't required to be HTML, it could be
> any format (probably most practical if it is HTML though, but SVG may
> certainly be more useful a format for describing an image.) It also
> isn't just for blind people, anyone wanting a long description would
> find it useful - you should certainly include the image for example.
In a thumbnail gallery, I consider that the thumbnail is just there to enable
the person to make a sensible choice about whether to have a look at the
target page. Any additional information should presumably be in the target
page? I prefer to keep the thumbnail galleries fairly "sparse".
If the person knows that it is a link, then the title in the gallery
presumably serves the same purpose - to help make a sensible choice about
whether to follow the link? Chris Morris' article informs me that the person
will know it is a link, so I just need to say what it is a link to.
(I'm not into SVG yet - a long way off. I'm still on JPEGs for both thumbnails
& full photographs. But my gallery links are never to the "jpg" file, they are
always to an "htm" file that has an "img" tag to the JPEG, so I have all the
power of the target HTML to add descriptive material).
Thanks.
Barry Pearson
[snip]
> Longdesc I'm never entirely sure about. Support for it isn't
> particularly good at the moment, so while it's useful for supplemental
> information the alt attribute needs to be good enough anyway.
>
> Given the poor support, where it's necessary a normal <a href> link
> afterwards seems the better option, which makes longdesc redundant.
>
> <img src="photo.jpg" alt="..."> <a href="longdesc.html">More
> information about ...</a>
> or
> <img src="photo.jpg" alt="Photo:"><a href="longdesc.html">Ducks in the
> pond</a> CSS-styled so that the <a> is a caption for the image where
> appropriate.
> or similar. I don't think <a href="...">D</a> is anything like widely
> used enough to be a recognised convention.
How do I "CSS-style so that the <a> is a caption for the image"? Is this some
specific feature of CSSs?
I do use CSSs for my photograph pages, but I just put a set of questions and
answers below the photograph:
What? Sally Lightfoot Crab.
Where? Galapagos Islands.
(The classes are called "question" and "answer" respectively).
http://www.barry.pearson.name/photography/pictures/eg95/eg95_22_23_3.htm
[snip]
> And since most speech browsers already indicate a link by fairly clear
> means (they prefix 'LINK' or change voice, most of the ones I've
> tried) it's already clear enough that it is a link.
>
> <a href="..."><img src="..." alt="Photo: ..."></a> should be clear
> enough.
Given that I want tooltips for my thumbnails, I intend to have "title" text in
the "img" tag in the thumbnail galleries. In that case, will the speech
browser speak the "title" text? If so, I was thinking of having alt="" because
there is then no need for additional text.
(If the thumbnail image doesn't load, it can be treated like a button that
doesn't load. Any description is really about the target photograph, not about
the thumbnail).
Jim Ley
<ne...@childsupportanalysis.co.uk> wrote:
>Jim Ley <j...@jibbering.com> wrote:
>In a thumbnail gallery, I consider that the thumbnail is just there to enable
>the person to make a sensible choice about whether to have a look at the
>target page. Any additional information should presumably be in the target
>page? I prefer to keep the thumbnail galleries fairly "sparse".
Certainly, I would suggest that the longdesc of a thumbnail can
sensibly be a link to the full size'd page as long as it contains text
etc. That would of course make it redundant, so you can leave it out.
>If the person knows that it is a link, then the title in the gallery
>presumably serves the same purpose - to help make a sensible choice about
>whether to follow the link? Chris Morris' article informs me that the person
>will know it is a link, so I just need to say what it is a link to.
The ALT should serve the same purpose yep, the title should be the
title of the image, for a thumbnail link to full size photo page, then
I'd suggest the ALT should be highlights of the key parts of the
image, that will give an idea of the full image content.
Jim.
Chris Morris
> > <img src="photo.jpg" alt="Photo:"><a href="longdesc.html">Ducks in the
> > pond</a> CSS-styled so that the <a> is a caption for the image where
> > appropriate.
> > or similar. I don't think <a href="...">D</a> is anything like widely
> > used enough to be a recognised convention.
>
> How do I "CSS-style so that the <a> is a caption for the image"? Is this some
> specific feature of CSSs?
<div class="thumbnail">
<img ...>
<a ...>...</a>
</div>
div.thumbnail img,
div.thumbnail a {
display: block;
}
div.thumbnail {
float: left;
}
For example. There's lots of ways to do it, that one doesn't work
particularly well in every situation, but it's not bad, and goes to
something reasonably sensible in text-mode too.
> > And since most speech browsers already indicate a link by fairly clear
> > means (they prefix 'LINK' or change voice, most of the ones I've
> > tried) it's already clear enough that it is a link.
> >
> > <a href="..."><img src="..." alt="Photo: ..."></a> should be clear
> > enough.
>
> Given that I want tooltips for my thumbnails, I intend to have
> "title" text in the "img" tag in the thumbnail galleries. In that
> case, will the speech browser speak the "title" text? If so, I was
> thinking of having alt="" because there is then no need for
> additional text.
Speech browsers will speak the alt and _may_ speak the title
(generally don't, I've found, but you might be able to reconfigure).
You can't rely on title being displayed, anyway.
However, if you have something like the 'caption <a>' above, or <a
href="..."><img ...>Link Text</a>, then an alt attribute of "" is
acceptable. Dig out a text browser such as Lynx or a speech
browser/screen reader and try things out, it'll be obvious reasonably
quickly what does and doesn't work.
> (If the thumbnail image doesn't load, it can be treated like a
> button that doesn't load. Any description is really about the target
> photograph, not about the thumbnail).
Yes, though the two are effectively the same image.
--
Chris
jake
Pearson <ne...@childsupportanalysis.co.uk> writes
>I am revising some photograph galleries. They use thumbnails for the links in
>the common way. I currently use "alt" text in the thumbnail "img" tags to
>describe the subject of the photograph. I'm pretty sure that is wrong.
>
[snip lots more good stuff]
>
Barry, this might help to visualise how voice browsers or screen readers
work:
(a) I go to your photography page:
http://www.Barry.Pearson.name/photography/
.... and this is what I hear (nb. links are spoken in a different
voice):
http://www.gododdin.demon.co.uk/ng/BARRY_M.TXT
(b) I 'see' that there are various galleries to be visited:
e.g. [Visit the "Landscape and light" gallery.]
So I can ask for a 'list of links', and I hear:
http://www.gododdin.demon.co.uk/ng/BARRY_ML.JPG
(just part of the list)
and choose to visit one of the galleries, in this case the one on China
(c) Reaching the Gallery (with its thumbnails) I hear:
http://www.gododdin.demon.co.uk/ng/BARRY_T.TXT
There's a lot of links on this page, so I ask for a list of links and
get:
http://www.gododdin.demon.co.uk/ng/BARRY_TL.JPG
(just part of the long list)
Unfortunately, you can see that all the links are here, including those
for the various resolution versions. This makes me wade through all the
content and all the links to get to the one I want.
(d) Anyway, I choose the 'Soldier in Tianmen Square' and hear:
http://www.gododdin.demon.co.uk/ng/BARRY_P.TXT
-------------------------------------------------------------------------
------
To learn more about the picture that I've focussed on, I need a separate
page describing the picture. The way to do this is to include a
'longdesc' in the <IMG> with the url of the 'description' page. As not
all screen readers and voice browsers understand 'longdesc' yet I would
also supplement this with the standard 'D-link'.
What this means is that I would (immediately) after the <IMG> tag add a
link in the format <A HREF="TheURL.HTM" TITLE="Page containing a more
detailed description of the picture">[D]</a>
So, the link goes on the main picture ... not the thumbnail.
When you design/re-design the pages, it's best to design with
'accessibility' in mind - as you appear to be doing.
Navigating thorough a collection of thumbnails that are each marked-up
with a suitable <Hn> would be useful. That way I can 'tab' from one
useful link to another and bypass all the links that I don't need to
consider (i.e. the ones for different resolutions).
Hope this helps.
regards
--
Jake
King Queen
>Not quite, a Long Description isn't required to be HTML, it could be
>any format (probably most practical if it is HTML though, but SVG may
>certainly be more useful a format for describing an image.)
Excuse my ignorance, what's SVG?
>It also
>isn't just for blind people, anyone wanting a long description would
>find it useful - you should certainly include the image for example.
Do text browsers such as Links or Lynx give an option of displaying
the long description? Thinking of it, I've not seen it do so, but I'm
not an expert.
>Oops... no it doesn't, well it does do it, but it's certainly not
>incorrect - you can't really claim any rendering of HTML content is
>incorrect since HTML defines no rendering.
'Pends on your point of view I suppose.
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"This majestical roof fretted with golden fire, why is it no other thing
to me than a foul and pestilent congregation of vapours?" Shakespeare
King Queen
<ne...@childsupportanalysis.co.uk> wrote:
>In a thumbnail gallery, I consider that the thumbnail is just there to enable
>the person to make a sensible choice about whether to have a look at the
>target page. Any additional information should presumably be in the target
>page? I prefer to keep the thumbnail galleries fairly "sparse".
>
>If the person knows that it is a link, then the title in the gallery
>presumably serves the same purpose - to help make a sensible choice about
>whether to follow the link?
Yes, you're probably right. I put the same longdescs on the thumbnails
and on the actual images, thinking that it doesn't make any difference
to "standard" visual browsers other than downloading the few extra
bytes of the "longdesc" attribute itself, that way people who would
use the longdesc attribute don't have to go to the subpage, but like
all these things it's up for debate I suppose.
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"It is a tactic that might work on a hilltop when it is concealed among
other trees but a fake tree on a street corner would be like putting
lipstick on a gorilla." - BBC News Online
King Queen
wrote:
>Longdesc I'm never entirely sure about. Support for it isn't
>particularly good at the moment, so while it's useful for supplemental
>information the alt attribute needs to be good enough anyway.
Well, yes, the ALT attribute needs to give an idea of what the image
is for and conveys, I agree. The longdesc is an optional addition that
gives more detail. For example at
http://www.earthfirstgathering.org.uk the front picture has a
functional ALT text, "Picture of Standing Stones in North Yorkshire.
Click image to enter site", whereas the longdesc gives a slightly more
"artistic" interpretation of the image, "Two standing stones against a
beautiful purple heather backdrop, some distant hills and a pale blue
sky. "
>Given the poor support, where it's necessary a normal <a href> link
>afterwards seems the better option, which makes longdesc redundant.
Yes, but unless there is a tide of support for longdescs, they won't
become standardised...
>I don't think <a href="...">D</a> is anything like widely
>used enough to be a recognised convention.
I don't either, but both these and longdescs are recommended in the
W3C WAI and unless people use them they won't become widely used. I.e.
if we avoid doing things as it's unconventional then doing them
remains unconventional, vicious circle, IYSWIM.
>In what way does 'click to go to enlargement' make it clear it's a
>link to speech browsers, which, by and large, don't have mice?
OK, perhaps it should say "select for enlargement" but I think you're
being picky, people using speech browsers are sure to know what "click
to" means.
>And since most speech browsers already indicate a link by fairly clear
>means (they prefix 'LINK' or change voice, most of the ones I've
>tried) it's already clear enough that it is a link.
>
><a href="..."><img src="..." alt="Photo: ..."></a> should be clear
>enough.
Except as there's no link text it does not make it explicit where the
link goes to. For example, we're taught to make sure that link text
makes sence out of context; link text "click here" is bloody useless
whereas "table of contents" gives an idea where it goes to. If you
come to a photo that's a link and all the alt text says is "Photo:
standing stones in Yorkshire" you've got no idea where it will take
you if you select that link. If it says "Photo: standing stones in
Yorkshire. Click here to to go the contents page" then you've got an
idea.
Maybe this would be better in the title attribute of the <a> tag, but
then I'm confused about how these are used by speech browsers.
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"Start today! Jack in yer job, have a lie in, cause trouble and then
save the world." - Schnews, http://www.schnews.org.uk
King Queen
<ne...@childsupportanalysis.co.uk> wrote:
>I'll investigate whether to use "longdesc" as well. I am wary of going OTT and
>creating too much repetition. If I have a photograph of a Pelican, should the
>"longdesc" describe that specific photograph ("Pelican flapping its wings"),
>or would a link to a fact sheet on Pelicans be better (which I could then use
>for all Pelican photographs)?
I tend to use the longdesc for a longer, more arty description that
wouldn't be appropriate for the alt text. For example, for partially
sighted people I might state that the big white thing in the top right
of the image is sky. Perhaps I'm being OTT, or patronising or
something, but it's a bit of a black art I think and probably
everybody disagrees :-)
>Thumbnail galleries are so common that I expected to find specific
>accessibility guidelines for them on the web. I'm sure they are there, but I
>haven't spotted them yet.
If you do find any please let me know!
>Tricky stuff! I bet most people get it wrong, as I've done.
I've come to the conclusion that there isn't a definite right or
wrong. Shame isn't it!
All the best
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"The vast majority of humanity is against the war. If the UN votes to
support it, it will only be because Washington has bullied, bribed or
terrorised poorer countries into supporting its plans." SchNews
Chris Morris
> On 29 Aug 2003 11:28:51 +0100, Chris Morris <c.i.m...@durham.ac.uk>
> wrote:
> >Given the poor support, where it's necessary a normal <a href> link
> >afterwards seems the better option, which makes longdesc redundant.
>
> Yes, but unless there is a tide of support for longdescs, they won't
> become standardised...
They're in recent Mozilla, and a few speech browsers. Don't know of
anything else.
However, there is already a sensible way without them to give a long
description for an image, so the attribute seems unnecessary even in
browsers that do support it.
> >I don't think <a href="...">D</a> is anything like widely
> >used enough to be a recognised convention.
>
> I don't either, but both these and longdescs are recommended in the
> W3C WAI and unless people use them they won't become widely used. I.e.
> if we avoid doing things as it's unconventional then doing them
> remains unconventional, vicious circle, IYSWIM.
True. *However*, <a href="...">Sensible text goes here</a> is IMO
more accessible, and is definitely better supported and recognised.
It makes longdesc pretty much obsolete.
D-links especially are a bad idea. View them in a 'list of links'
context and it's as bad as a bunch of images with no alt text.
> >In what way does 'click to go to enlargement' make it clear it's a
> >link to speech browsers, which, by and large, don't have mice?
>
> OK, perhaps it should say "select for enlargement" but I think you're
> being picky, people using speech browsers are sure to know what "click
> to" means.
Probably. But given the state of the web, it might mean 'select this
link', it might mean 'activate this poorly written Javascript
OnClick', so best to avoid the ambiguity by avoiding the phrase where
possible.
> ><a href="..."><img src="..." alt="Photo: ..."></a> should be clear
> >enough.
>
> Except as there's no link text it does not make it explicit where the
> link goes to. For example, we're taught to make sure that link text
> makes sence out of context; link text "click here" is bloody useless
> whereas "table of contents" gives an idea where it goes to. If you
Yes.
> come to a photo that's a link and all the alt text says is "Photo:
> standing stones in Yorkshire" you've got no idea where it will take
> you if you select that link.
Well, I'd imagine that it would either go to a page about standing
stones in Yorkshire, *or* go to an image of standing stones in
Yorkshire. Something relevant to standing stones in Yorkshire, anyway.
> If it says "Photo: standing stones in Yorkshire. Click here to to go
> the contents page" then you've got an idea.
Hmm, I think I'd do
<a href="toc.html"><img src="stand.jpg" alt="Table of contents"
title="Photo: standing stones in Yorkshire"></a>
or more likely
<img alt="Photo: standing stones in Yorkshire" src="stand.jpg">
<a href="toc.html">Table of contents</a>
in that case. Almost certainly the latter, since I don't expect many
graphical users will be familiar with the convention of using pictures
of Yorkshire standing stones to represent tables of contents, though
if it was in fact a picture of said standing stones, with the text
'table of contents' written on top of it, the former would be better.
> Maybe this would be better in the title attribute of the <a> tag, but
> then I'm confused about how these are used by speech browsers.
Sometimes they get read, sometimes not. Title is always optional
extra information that, in _any_ circumstances, shouldn't be required by
the user.
--
Chris
Barry Pearson
Jim Ley
<kq.larts...@kingqueen.org.uk> wrote:
>On Fri, 29 Aug 2003 10:09:03 GMT, j...@jibbering.com (Jim Ley) wrote:
>
>>Not quite, a Long Description isn't required to be HTML, it could be
>>any format (probably most practical if it is HTML though, but SVG may
>>certainly be more useful a format for describing an image.)
>
>Excuse my ignorance, what's SVG?
Scalable Vector Graphics, it's a markup language for images.
http://jibbering.com/2002/8/img-desc.svg
(or
http://jibbering.com/2003/8/img-desc.jpg if you don't have an SVG
Viewer)
Is a description of a photo of mine -
http://jibbering.com/imgs/shepherds.jpg
(it's actually machine generated from metadata so it's not
particularly good, but I think it shows how non straight plain text
can be more useful in describing images)
>Do text browsers such as Links or Lynx give an option of displaying
>the long description?
Long Description doesn't just mean text, indeed as it's a standalone
page, it needs to be accessible in itself, which includes people who
find text difficult, the longdesc page should surely have the image on
it, at a very minimum.
Jim.
King Queen
wrote:
>Navigating thorough a collection of thumbnails that are each marked-up
>with a suitable <Hn> would be useful. That way I can 'tab' from one
>useful link to another and bypass all the links that I don't need to
>consider (i.e. the ones for different resolutions).
That's an interesting thought, then perhaps we could use CSS to format
them so they don't look overly different from other links if we
wished.
I do wonder though if this is abuse of the <h?> tags, which are AIUI
purely meant to delineate various levels of headings. As the thumbnail
delineated by <h?> isn't a heading of a subsection of the page, would
it be appropriate? Is there any way we could use, say, the <div> tag
instead? Or would that not have the same effect on speech browsers?
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"As with most things, we are told how wonderful and lovely and legal and
necessary it is. Hidden under this message is that it's a profit-making
scam for fat dead white middle-class cunts." Drew on insurance
King Queen
>Scalable Vector Graphics, it's a markup language for images.
Cheers.
>(or
>http://jibbering.com/2003/8/img-desc.jpg if you don't have an SVG
>Viewer)
I can see the usefulness of this. Is it widely used? I'd not heard of
it before.
>Long Description doesn't just mean text, indeed as it's a standalone
>page, it needs to be accessible in itself, which includes people who
>find text difficult, the longdesc page should surely have the image on
>it, at a very minimum.
I can see how a broken up image, in the manner in which you did above,
could be of use, but what's the point in just repeating the image
itself?
Like all these things, straining to reach the perfectly accessible
webpage is a thankless task I think, as there are so many different
opinions on what to do...
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"What good will it do social cohesion when people chat regularly to
people on the other side of the world but don't know the name of their
next-door neighbours?" - Dr Drew
Jim Dabell
> On Fri, 29 Aug 2003 11:02:26 +0100, King Queen
> <kq.larts...@kingqueen.org.uk> wrote:
[snip]
>>As for tooltips: IE incorrectly shows ALT text as tooltips, as you're
>>probably aware.
>
> Oops... no it doesn't, well it does do it, but it's certainly not
> incorrect - you can't really claim any rendering of HTML content is
> incorrect since HTML defines no rendering.
"Alternative" says to me that one or the other should be used for the common
case, not both.
In any case, I thought I heard that the latest service pack removed this
behaviour. Is this true?
--
Jim Dabell
King Queen
wrote:
>> Yes, but unless there is a tide of support for longdescs, they won't
>> become standardised...
>
>They're in recent Mozilla, and a few speech browsers. Don't know of
>anything else.
OK, I didn't express myself well, I meant that unless lots of people
write them into webpages then lots of more people won't hear of them
or use them either.
>D-links especially are a bad idea. View them in a 'list of links'
>context and it's as bad as a bunch of images with no alt text.
You're right, I never thought of that. In that case the WAI are self
contradictory - on one point they say "make sure link text makes sense
out of context" then on the other they're advocating links which
contain only the text "D"! Wonder if it's been pointed out to them.
>Probably. But given the state of the web, it might mean 'select this
>link', it might mean 'activate this poorly written Javascript
>OnClick', so best to avoid the ambiguity by avoiding the phrase where
>possible.
Good point, will use your example in the future.
>or more likely
><img alt="Photo: standing stones in Yorkshire" src="stand.jpg">
><a href="toc.html">Table of contents</a>
I always make sure that there are text alternatives to images used as
links. Using the image as a link is an addition...
>Sometimes they get read, sometimes not. Title is always optional
>extra information that, in _any_ circumstances, shouldn't be required by
>the user.
OK, cheers.
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"Society drives people crazy with lust and calls it advertising" J. Lahr
Jim Ley
<kq.larts...@kingqueen.org.uk> wrote:
>On Fri, 29 Aug 2003 14:45:37 GMT, j...@jibbering.com (Jim Ley) wrote:
>>(or
>>http://jibbering.com/2003/8/img-desc.jpg if you don't have an SVG
>>Viewer)
>
>I can see the usefulness of this. Is it widely used? I'd not heard of
>it before.
SVG? - I know thousands of folk, and many resources, and many sites
delivering it.
RDF generated image metadata converted into SVG for describing images,
I know a fair few, and quite a lot of tools interest in the area in
the experimental world.
>I can see how a broken up image, in the manner in which you did above,
>could be of use, but what's the point in just repeating the image
>itself?
Because a user needs to see it to help them understand the
description! - You're not repeating the image itself in any case,
because the longdesc is a seperate page, that page needs to be
accessible, it's not part of the other page, it's distinct, and needs
to standalone on its own two feet.
Jim.
Barry Pearson
response below).
jake <ja...@gododdin.demon.co.uk> wrote:
> In message <fpE3b.80$b82....@newsfep1-win.server.ntli.net>, Barry
> Pearson <ne...@childsupportanalysis.co.uk> writes
[snip]
> Navigating thorough a collection of thumbnails that are each marked-up
> with a suitable <Hn> would be useful. That way I can 'tab' from one
> useful link to another and bypass all the links that I don't need to
> consider (i.e. the ones for different resolutions).
>
> Hope this helps.
Thanks. That helped a lot. Must it be Hn, not tabindex? Should I bypass the
links at the top of the page which act as buttons to the rest of the web site?
I'll experiment.
While I digest that, could you please give your view on another web site? It
is this next one, that I intend to launch soon, that I am most concened about
because it is intended to provide more than photographs. It is called "Birds
and Animals info". While the information is still largely photographs (all one
resolution, so you won't see all those extra links), I am adding extra
features. Here is a pre-launch version - I've been trying it out with various
validation services on the web, with mixed results.
http://www.birdsandanimals.info/
One extra feature is that (nearly) every photograph page has "pre-configured
searches". These are links to the Google search engine with parameters
specific to the subject of the photograph. So if the subject is "Sally
Lightfoot Crab, Grapsus grapsus", there will be two links below it, one for a
normal web search on "Grapsus grapsus", and the other for a Google image
search on that. The idea is that I will have validated in advance that the
search makes sense, so all the viewer has to do is make the link and Google
will supply a ranked set of web sites on the topic. The policy is "to add
value to the Internet, not to duplicate it", so I am trying to avoid writing
pages that don't add anything new.
What I can't judge is whether it will be clear enough what is going on. Or
whether the returned Google page itself is accessible! (I checked this method
with the Google brand-management people and they were happy enough).
In some cases, there are also links to fact sheets on the same web site, for
example "Flamingos" or "Galapagos Islands".
(I've tried accessing this web site using a Beta version of Mozilla Firebird.
For some reason it doesn't use the style sheet. But it does when I access it
on my PC. And the W3C validation service can access the CSS. Hm!)
jake
<kq.larts...@kingqueen.org.uk> writes
>On Fri, 29 Aug 2003 14:52:29 +0100, jake <ja...@gododdin.demon.co.uk>
>wrote:
>
>>Navigating thorough a collection of thumbnails that are each marked-up
>>with a suitable <Hn> would be useful. That way I can 'tab' from one
>>useful link to another and bypass all the links that I don't need to
>>consider (i.e. the ones for different resolutions).
>
>That's an interesting thought, then perhaps we could use CSS to format
>them so they don't look overly different from other links if we
>wished.
>
>I do wonder though if this is abuse of the <h?> tags, which are AIUI
>purely meant to delineate various levels of headings. As the thumbnail
>delineated by <h?> isn't a heading of a subsection of the page, would
>it be appropriate? Is there any way we could use, say, the <div> tag
>instead? Or would that not have the same effect on speech browsers?
>
with designating the thumbnail as the start of a 'subsection' containing
that image followed by other links to variations of the image.
A table would also work quite well :-)
regards.
--
Jake
Jim Ley
<jim-u...@jimdabell.com> wrote:
>Jim Ley wrote:
>
>> On Fri, 29 Aug 2003 11:02:26 +0100, King Queen
>> <kq.larts...@kingqueen.org.uk> wrote:
>[snip]
>>>As for tooltips: IE incorrectly shows ALT text as tooltips, as you're
>>>probably aware.
>>
>> Oops... no it doesn't, well it does do it, but it's certainly not
>> incorrect - you can't really claim any rendering of HTML content is
>> incorrect since HTML defines no rendering.
>
>"Alternative" says to me that one or the other should be used for the common
>case, not both.
So you're saying the only piece of rendering HTML4.01 defines is on
ALT text, they've thrown everything else, but choose to define
specific behaviour to the intentional detriment of certain users, and
making it impossible for those user agents to behave conformantly?
That's ridiculous.
In any case, Mozilla (for example) would be just as flawed as it also
renders ALT and the image at the same time.
>In any case, I thought I heard that the latest service pack removed this
>behaviour. Is this true?
That would be disastrous, and destroy the accessibilty of IE, but I
don't believe it's true.
Jim.
jake
<kq.larts...@kingqueen.org.uk> writes
>On 29 Aug 2003 15:39:20 +0100, Chris Morris <c.i.m...@durham.ac.uk>
>wrote:
>>> Yes, but unless there is a tide of support for longdescs, they won't
>>> become standardised...
>>
>>They're in recent Mozilla, and a few speech browsers. Don't know of
>>anything else.
>
>OK, I didn't express myself well, I meant that unless lots of people
>write them into webpages then lots of more people won't hear of them
>or use them either.
>
>>D-links especially are a bad idea. View them in a 'list of links'
>>context and it's as bad as a bunch of images with no alt text.
>
>You're right, I never thought of that. In that case the WAI are self
>contradictory - on one point they say "make sure link text makes sense
>out of context" then on the other they're advocating links which
>contain only the text "D"! Wonder if it's been pointed out to them.
A 'D-link' is the de-facto standard way of linking to a description
page. People using the kind of assistive technology that we're
discussing will know what a D-link is. In a list of links, or in the
page itself, you really can't mistake one.
e.g. "Image of Chinese Soldier" ["Image Description"] "Deeee"
The "Image Description" link coming from the longdesc if the reader
understands it and the 'Deeee' link being there whether or not the
reader knows about longdesc.
D-links are a 'good thing' if the image calls for a longdesc.
>
>>Probably. But given the state of the web, it might mean 'select this
>>link', it might mean 'activate this poorly written Javascript
>>OnClick', so best to avoid the ambiguity by avoiding the phrase where
>>possible.
>
>Good point, will use your example in the future.
>
>>or more likely
>><img alt="Photo: standing stones in Yorkshire" src="stand.jpg">
>><a href="toc.html">Table of contents</a>
>
>I always make sure that there are text alternatives to images used as
>links. Using the image as a link is an addition...
>
>>Sometimes they get read, sometimes not. Title is always optional
>>extra information that, in _any_ circumstances, shouldn't be required by
>>the user.
>
>OK, cheers.
>
--
Jake
Chris Morris
> (I've tried accessing this web site using a Beta version of Mozilla Firebird.
> For some reason it doesn't use the style sheet. But it does when I access it
> on my PC. And the W3C validation service can access the CSS. Hm!)
HTTP/1.0 200 OK
Server: Zeus/3.4
Date: Fri, 29 Aug 2003 15:32:30 GMT
Content-Length: 2636
Content-Type: text/plain
Ah, there we go (thought so).
CSS stylesheets must be served with the content-type text/css.
--
Chris
Chris Morris
> A 'D-link' is the de-facto standard way of linking to a description
> page. People using the kind of assistive technology that we're
> discussing will know what a D-link is.
And everyone else will get confused. Search engines included,
probably a lot of Lynx users too, and probably anyone who's just on
dialup and has turned image loading off.
> In a list of links, or in the page itself, you really can't mistake
> one.
In the page itself it's okay. I'm not sure it is the de-facto
standard way precisely because it's used so little. While there's no
real de-facto standard, it's probably best to work out what will work
well for everyone.
> e.g. "Image of Chinese Soldier" ["Image Description"] "Deeee"
Okay, now assume that the image isn't a link itself, and we're cycling
through the list of links.
"Some text link" "Some text link" "Deee" "Deee" "Deee" "Deee" "Deee"
"Some text link"
Not so helpful. Compare with
"Some text link" "Some text link" "Information about fish population graph"
"Information about rainfall graph" etc.
When read in standard mode
'Graph: Fish populations have declined over the last five years'
"Information about fish population graph"
Still makes sense.
(' for non-link text, " for link text)
> The "Image Description" link coming from the longdesc if the reader
> understands it and the 'Deeee' link being there whether or not the
> reader knows about longdesc.
>
> D-links are a 'good thing' if the image calls for a longdesc.
Links to a description are a good thing, yes. I remain to be
convinced that 'D' is appropriate link text for them as opposed to
something more sensible.
For example:
<img src="graph.png" alt="Graph: Fish populations have declined over
the last five years"> <a href="details.html">Information about fish
population graph</a>
details.html then contains various information about the graph, more
detailed description, data tables, whatever.
I think this approach works at least as well as 'D-links' in speech,
and better than D-links in other (graphical and non-graphical) media.
--
Chris
Jim Ley
wrote:
>jake <ja...@gododdin.demon.co.uk> writes:
>> A 'D-link' is the de-facto standard way of linking to a description
>> page. People using the kind of assistive technology that we're
>> discussing will know what a D-link is.
>
>And everyone else will get confused. Search engines included,
>probably a lot of Lynx users too, and probably anyone who's just on
>dialup and has turned image loading off.
A D link should only be used with a TITLE describing the linked
resource, so link list methods should not have a problem with it.
However I agree they're not to be preferred over a an actual title of
the photo which is also a link to the description, as you suggest
here:
><img src="graph.png" alt="Graph: Fish populations have declined over
>the last five years"> <a href="details.html">Information about fish
>population graph</a>
Jim.
Andy Jacobs
<j...@jibbering.com> wrote:
> On Fri, 29 Aug 2003 15:50:50 +0100, Jim Dabell
> <jim-u...@jimdabell.com> wrote:
<snip>
> In any case, Mozilla (for example) would be just as flawed as it also
> renders ALT and the image at the same time.
>
This is probably a stupid question... Is IE based on Mozilla? I've made
that assumption as IE on a PC displays ALT text like tool tips, even if the
image is displayed. IE on a Mac, however, doesn't.
jake
>(I just accidentally posted a nul response, then cancelled it. Sorry! Real
>response below).
>
>jake <ja...@gododdin.demon.co.uk> wrote:
>> In message <fpE3b.80$b82....@newsfep1-win.server.ntli.net>, Barry
>> Pearson <ne...@childsupportanalysis.co.uk> writes
>[snip]
>> Navigating thorough a collection of thumbnails that are each marked-up
>> with a suitable <Hn> would be useful. That way I can 'tab' from one
>> useful link to another and bypass all the links that I don't need to
>> consider (i.e. the ones for different resolutions).
>>
>> Hope this helps.
>
>Thanks. That helped a lot. Must it be Hn, not tabindex?
I wouldn't worry about Hn. Not too practical unless the layout was
changed quite a bit.
Actually, navigation on the thumbnails page isn't too bad as some
assistive technologies will allow you to go into 'table navigation' mode
and move freely around the cells and headings of the table.
It's just that you need to know the construction of the table (because
row entries aren't consistent) -- then it's fairly simple.
The browser will tell me that the table is 5 columns wide by 6 rows
deep. I can then move around the table quite freely, with the browser
reading the contents of each cell to me (links in a different voice).
Once I know that I need to skip alternate rows, then things are pretty
straightforward. I just need to know the table layout in the first
place.
regards
>Should I bypass the
>links at the top of the page which act as buttons to the rest of the web site?
>I'll experiment.
>
Yes. That would be a good idea. You can put a 'bypass navigation' link
as the first entry -- and make it invisible if you want to by making the
link a 1-pixel gif.
>
[snip digression - to be looked at]
>
regards.
--
Jake
Barry Pearson
Gosh! Is this a fault in the server? Or am I uploading it wrong? Or what?
(I use Dreamweaver to upload it. Dreamweaver appears to think it is a CSS).
Note that Firebird is the only thing I've personally known to have trouble. I
don't know how many others have actually failed! Is Firebird very strict?
Jim Dabell
[snip]
> This is probably a stupid question... Is IE based on Mozilla?
No. Lots of other browsers are though, for instance, Netscape is based on
Mozilla. Internet Explorer and Netscape share a common ancestor - the
Mosaic browser - but that was a long time ago and I doubt they share a
single line of code any more.
> I've made that assumption as IE on a PC displays ALT text like tool tips,
> even if the image is displayed. IE on a Mac, however, doesn't.
Internet Explorer for the Mac is a completely different codebase to Internet
Explorer for Windows. At one point, the Mac version was far better than
the Windows version, but it has been neglected recently. It still does
some things better though (e.g. MAC IE 5.5 can handle PNG images properly,
Win IE 6.0 botches the alpha channel).
--
Jim Dabell
Barry Pearson
Gosh! Is this a fault in the server? Or am I uploading it wrong? Or what?
(I use Dreamweaver to upload it. Dreamweaver appears to think it is a CSS).
Note that Firebird is the only thing I've personally known to have trouble. I
don't know how many others have actually failed! Is Firebird very strict?
--
Barry Pearson
http://www.Barry.Pearson.name/photography/
Barry Pearson
> On Fri, 29 Aug 2003 15:50:50 +0100, Jim Dabell
> <jim-u...@jimdabell.com> wrote:
> >In any case, I thought I heard that the latest service pack removed this
> >behaviour. Is this true?
>
> That would be disastrous, and destroy the accessibilty of IE, but I
> don't believe it's true.
I use IE6. I have just checked whether there are any upgrades and the MS site
says not.
Version: 6.0.2800.1106
SP1, Q324929, Q810847, Q813951, Q813489, Q330994, Q818529, Q822925
My version displays tooltips for "alt" text.
Given the amount of useful "alt" text out there, I would hate to lose this!
Richard Watson
> Internet Explorer and Netscape share a common ancestor - the
> Mosaic browser - but that was a long time ago and I doubt they share a
> single line of code any more.
Does anyone know of a browser family tree anywhere?
--
Richard Watson
http://www.opencolo.com/
High Quality, Value for money colocation
Barry Pearson
> On Fri, 29 Aug 2003 15:50:50 +0100, Jim Dabell
> <jim-u...@jimdabell.com> wrote:
> >In any case, I thought I heard that the latest service pack removed this
> >behaviour. Is this true?
>
> That would be disastrous, and destroy the accessibilty of IE, but I
> don't believe it's true.
I use IE6. I have just checked whether there are any upgrades and the MS site
Jim Dabell
> Chris Morris <c.i.m...@durham.ac.uk> wrote:
[snip]
>> CSS stylesheets must be served with the content-type text/css.
>
> Gosh! Is this a fault in the server?
A misconfiguration. Contact your server admin and get him to fix it.
Telling him that files ending in .css should be sent out as text/css should
be enough for him to go on - if not, you need a new admin :)
[snip]
> Note that Firebird is the only thing I've personally known to have
> trouble. I don't know how many others have actually failed! Is Firebird
> very strict?
Anything based on Mozilla will have trouble, I don't know about other
browsers. Note that this behaviour depends on which rendering mode you are
in (google for "doctype switching" for details).
--
Jim Dabell
Jim Dabell
> On Fri, 29 Aug 2003 15:50:50 +0100, Jim Dabell
> <jim-u...@jimdabell.com> wrote:
>
>>Jim Ley wrote:
>>
>>> On Fri, 29 Aug 2003 11:02:26 +0100, King Queen
>>> <kq.larts...@kingqueen.org.uk> wrote:
>>[snip]
>>>>As for tooltips: IE incorrectly shows ALT text as tooltips, as you're
>>>>probably aware.
>>>
>>> Oops... no it doesn't, well it does do it, but it's certainly not
>>> incorrect - you can't really claim any rendering of HTML content is
>>> incorrect since HTML defines no rendering.
>>
>>"Alternative" says to me that one or the other should be used for the
>>common case, not both.
>
> So you're saying the only piece of rendering HTML4.01 defines is on
> ALT text,
Not at all. I'm saying that in the common case, rendering both is a
mistake. The specification seems to support me on this:
"Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors
specify alternate text to serve as content when the element cannot be
rendered normally."
Now why would they call it "alternate text", and specify that it should be
rendered under specific circumstances, if it's not an alternate, and can be
rendered under normal circumstances?
By the way, HTML 4.01 defines rendering rules for <object>. I didn't bother
looking any further, but I reckon there are other examples.
> they've thrown everything else, but choose to define
> specific behaviour to the intentional detriment of certain users, and
> making it impossible for those user agents to behave conformantly?
> That's ridiculous.
Yes, it is ridiculous. It's not what I was saying at all though.
>>"Alternative" says to me that one or the other should be used for the
>>common case, not both.
"Should". "Common case". Displaying alternative representations of the
same content at the same time for the common case is a mistake in my
opinion.
> In any case, Mozilla (for example) would be just as flawed as it also
> renders ALT and the image at the same time.
I wasn't aware of this. Under what circumstances?
>>In any case, I thought I heard that the latest service pack removed this
>>behaviour. Is this true?
>
> That would be disastrous, and destroy the accessibilty of IE, but I
> don't believe it's true.
I don't see how. Care to enlighten me?
--
Jim Dabell
jake
<c.i.m...@durham.ac.uk> writes
[snip]
> I'm not sure it is the de-facto
>standard way precisely because it's used so little. While there's no
>real de-facto standard, it's probably best to work out what will work
>well for everyone.
Quote from the RNIB website http://www.rnib.org.uk :
Complex images. You should provide an additional, longer description for
more complex images, like charts and graphs. This is what the LONGDESC
attribute is for, but unfortunately not all browsers or screen readers
pick up on this attribute, so you shouldn't rely solely on the use of
LONGDESC. One alternative is to place a "d" (for "description") next to
the image and linking that to a page containing the detailed
description. Other alternatives are to include the information conveyed
by the image in the text which accompanies it, or to make the image
itself a link to a separate page containing the detailed description. In
this case, the ALT text for the image should indicate the nature of the
link, e.g. "Graph showing the increase in sales over the past 10 years -
link to detailed description".
>
>> e.g. "Image of Chinese Soldier" ["Image Description"] "Deeee"
>
>Okay, now assume that the image isn't a link itself, and we're cycling
>through the list of links.
>
>"Some text link" "Some text link" "Deee" "Deee" "Deee" "Deee" "Deee"
>"Some text link"
>
>Not so helpful.
I'm not sure I understand why you'd want to have a d-link if you've
already got a narrative link to the description page sited next to the
image. Perhaps you could explain further? (give me some HTML so that I
see what you're trying to achieve)
>Compare with
>"Some text link" "Some text link" "Information about fish population graph"
>"Information about rainfall graph" etc.
>
>When read in standard mode
>
>'Graph: Fish populations have declined over the last five years'
>"Information about fish population graph"
>
>Still makes sense.
>
>(' for non-link text, " for link text)
Sure. There's nothing wrong with that approach.
>
>> The "Image Description" link coming from the longdesc if the reader
>> understands it and the 'Deeee' link being there whether or not the
>> reader knows about longdesc.
>>
>> D-links are a 'good thing' if the image calls for a longdesc.
>
>Links to a description are a good thing, yes. I remain to be
>convinced that 'D' is appropriate link text for them as opposed to
>something more sensible.
Just so long as the information is easily made available it really
doesn't matter. Longdesc, D-link, narative .... you chose.
>
>For example:
>
><img src="graph.png" alt="Graph: Fish populations have declined over
>the last five years"> <a href="details.html">Information about fish
>population graph</a>
>
>details.html then contains various information about the graph, more
>detailed description, data tables, whatever.
>
>I think this approach works at least as well as 'D-links' in speech,
>and better than D-links in other (graphical and non-graphical) media.
>
Sure.
regards.
--
Jake
jake
<j...@jibbering.com> writes
>
[snip]
>A D link should only be used with a TITLE describing the linked
>resource, so link list methods should not have a problem with it.
[snip]
>
>Jim.
Like to run that one past me again, Jim ? -- with maybe an example.
Thanks.
--
Jake
Andy Jacobs
Dabell" <jim-u...@jimdabell.com> wrote:
> Andy Jacobs wrote:
>
> [snip]
>> This is probably a stupid question... Is IE based on Mozilla?
>
> No. Lots of other browsers are though, for instance, Netscape is based on
> Mozilla. Internet Explorer and Netscape share a common ancestor - the
> Mosaic browser - but that was a long time ago and I doubt they share a
> single line of code any more.
Blimey, that takes me back. Wasn't Mosaic the browser used on the default
Compuserve install, when e-mail addresses were something like
726,87...@compuserve.com?
>
>
>> I've made that assumption as IE on a PC displays ALT text like tool tips,
>> even if the image is displayed. IE on a Mac, however, doesn't.
>
> Internet Explorer for the Mac is a completely different codebase to Internet
> Explorer for Windows. At one point, the Mac version was far better than
> the Windows version, but it has been neglected recently. It still does
> some things better though (e.g. MAC IE 5.5 can handle PNG images properly,
> Win IE 6.0 botches the alpha channel).
I have found that IE and Safari on the Mac are a little flawed in several
areas. I use a little java applet, for example, when I'm running a web cam.
On a PC, it updates every x seconds, on a Mac, you just get the image that
is current when the window opens and that's your lot unless you close the
window and re-open it. I've tried 2 or 3 different applets and they all do
the same.
Alan J. Flavell
> My version displays tooltips for "alt" text.
>
> Given the amount of useful "alt" text out there, I would hate to lose this!
"useful" for what? The primary purpose of alt text is to serve as
a textual alternative to the image.
As Jim has shown, there can be reasons for wanting to optionally
access the alt text even though the image is being shown - so far, so
good - but its primary purpose is documented to be for when the image
is NOT being shown: (mis)using the alt text as a surrogate for the
"title" attribute (which is the meaning that I take from your
posting - feel free to correct it if that's wrong) isn't helpful.
And if the title attribute is properly provided, IE versions have
displayed it in several recent versions, just as Mozilla does.
The geriatric relics of NN4.* have to be of little concern in this
regard, even if some small proportion of users is still using it.
Barry Pearson
> On Fri, 29 Aug 2003, Barry Pearson wrote:
>
> > My version displays tooltips for "alt" text.
> >
> > Given the amount of useful "alt" text out there, I would hate to lose
> > this!
>
> "useful" for what? The primary purpose of alt text is to serve as
> a textual alternative to the image.
Thanks for replying. I came across some of your writing on this topic when I
was searching for guidelines, and found it useful.
My comment wasn't about whether "alt" text should be useful as tooltips. My
comment was that it currently is useful. This is because there is a lot of
"alt" text out there at the moment, and I find some of it adds to the material
I am looking at. Yes, that is poor authoring - but there is quite a bit of
that about!
My aim for this thread was both to understand the spirit of what these
attributes are for, and to find what happened to these attributes in practice.
I am trying to get a couple of web sites "right", whatever that means. It
means "in theory" and "in practice". And the latter includes accessibility
issues.
> As Jim has shown, there can be reasons for wanting to optionally
> access the alt text even though the image is being shown - so far, so
> good - but its primary purpose is documented to be for when the image
> is NOT being shown: (mis)using the alt text as a surrogate for the
> "title" attribute (which is the meaning that I take from your
> posting - feel free to correct it if that's wrong) isn't helpful.
I realise that. But note the specific context of this thread - thumbnails.
These are a special case that I believe needs extra thought.
In one sense, a thumbnail is a small photographic image. So it can be treated
as such. The "alt" text can be a genuine alternative for the image, trying to
convey the same "information". If the thumbnail is a Sally Lightfoot Crab,
then the "alt" text can say so, and perhaps say what the crab is doing.
But in another sense, a thumbnail is a button. We know that you shouldn't say
"yellow ball" as the "alt" text for a button! What the button looks like is
irrelevant if you don't load it. You want to know, by some means available to
you (tooltips, speech, convention, etc), based on something in the coding
("alt", "title", and/or something else), what your options are, so that you
can make a sensible decision. Does the fact that the thumbnail happens to be a
Sally Lightfoot Crab, instead of a yellow ball, help? (Especially if it didn't
load). What is actually important is what it provides a link to.
If I linked to my full-size Sally Lightfoot Crab photograph using a button, I
believe I should use alt="" and a suitable title. (OK - perhaps a not a good
way of linking to a photograph, but I'm thinking around the principles here).
But the "instinct" with a thumbnail is to put in "alt" text. I am querying
that.
> And if the title attribute is properly provided, IE versions have
> displayed it in several recent versions, just as Mozilla does.
> The geriatric relics of NN4.* have to be of little concern in this
> regard, even if some small proportion of users is still using it.
Chuckle! I've had to give up on users of early NNs. The more style-information
I push into CSSs, the worse I make things for early browsers. Tough.
But I've just downloaded a trial version of the IBM "Home Page Reader", simply
to get a feel for the accessibility of my sites. As far as I can tell, it
doesn't speak "title" information, and thumbnails with alt="" but a title get
ignored by default. There is an option to have images without "alt" text
recognised, but I don't think it then uses the "title" text. I'm still
experimenting.
This is turning out to be a compromise between the intent of these attributes,
their use in practice on the web, and the capability of the (important)
browsers and readers.
Barry Pearson
[snip]
Thanks for that. I'll experiment.
Can you point me to some readers that I can try? Which are the important ones?
I've just downloaded a trial version of the IBM "Home Page Reader" to get a
feel for how they work in practice. But I don't know if that is mainstream or
irrelevant. We are warned against designing web sites for particular browsers.
The same should surely apply to "accessibility technology" too - but does it?
Barry Pearson
> Barry Pearson wrote:
>
> > Chris Morris <c.i.m...@durham.ac.uk> wrote:
> [snip]
> >> CSS stylesheets must be served with the content-type text/css.
> >
> > Gosh! Is this a fault in the server?
>
> A misconfiguration. Contact your server admin and get him to fix it.
> Telling him that files ending in .css should be sent out as text/css
> should be enough for him to go on - if not, you need a new admin :)
Thanks. Will do.
> [snip]
> > Note that Firebird is the only thing I've personally known to have
> > trouble. I don't know how many others have actually failed! Is Firebird
> > very strict?
>
> Anything based on Mozilla will have trouble, I don't know about other
> browsers. Note that this behaviour depends on which rendering mode you
> are in (google for "doctype switching" for details).
My pages have a DOCTYPE 4.01 Transitional with URL. I think that is a fairly
strict check but allowing deprecated features? (I ran some of them past the
W3C validation service, and it accessed the CSS! It even told me I could use
their button on those pages. Was this a flaw in the validation - should it
have failed?)
Barry Pearson
> On Fri, 29 Aug 2003 12:17:42 +0100, "Barry Pearson"
> <ne...@childsupportanalysis.co.uk> wrote:
>
> >Jim Ley <j...@jibbering.com> wrote:
> >In a thumbnail gallery, I consider that the thumbnail is just there to
> >enable the person to make a sensible choice about whether to have a look
> >at the target page. Any additional information should presumably be in
> >the target page? I prefer to keep the thumbnail galleries fairly
> >"sparse".
[snip]
> The ALT should serve the same purpose yep, the title should be the
> title of the image, for a thumbnail link to full size photo page, then
> I'd suggest the ALT should be highlights of the key parts of the
> image, that will give an idea of the full image content.
Thanks. But my query here is - is it "title" rather than "alt" that should
provide highlights of the key parts of the "full size" image? It surely isn't
the purpose of thumbnail "alt" to discuss another page/image?
I coming to the conclusion that "theory" says have null "alt" for the
thumbnail and a full "title", but "practice" says "use both"!
Liz
"Barry Pearson" <ne...@childsupportanalysis.co.uk> wrote:
> Alan J. Flavell <fla...@ph.gla.ac.uk> wrote:
>
> > And if the title attribute is properly provided, IE versions have
> > displayed it in several recent versions, just as Mozilla does.
> > The geriatric relics of NN4.* have to be of little concern in this
> > regard, even if some small proportion of users is still using it.
>
> Chuckle! I've had to give up on users of early NNs. The more style-information
> I push into CSSs, the worse I make things for early browsers. Tough.
>
I must be particularly dense on this point.
This is where the whole accessibility thing has me totally bamboozled.
Still.
*If* the main point of your site is your photographs (and I'm assuming from
your original post that it is), why is accessibility for a text-only or
text-to-speech user (so that they can read what is in the pix they can't, or
choose not to see) more important than making your pix available to people
(like me) with older browsers which don't read CSS but do show pictures,
tables and frames? (Apart from the solely legalistic argument)
Liz
--
Virtual Liz at http://www.v-liz.co.uk
Kenya; Tanzania; India; Seychelles
New Aug '03: Namibia
Jim Ley
<ne...@childsupportanalysis.co.uk> wrote:
>Jim Ley <j...@jibbering.com> wrote:
>> The ALT should serve the same purpose yep, the title should be the
>> title of the image, for a thumbnail link to full size photo page, then
>> I'd suggest the ALT should be highlights of the key parts of the
>> image, that will give an idea of the full image content.
>
>Thanks. But my query here is - is it "title" rather than "alt" that should
>provide highlights of the key parts of the "full size" image? It surely isn't
>the purpose of thumbnail "alt" to discuss another page/image?
The purpose of the thumbnail is to give people an idea of what the
image is for them to see if they want to view the full sized one.
TITLE, is the title of the image.
Imagine you weren't using images, you'd have <a href="..."> text </a>
and that text is discussing the other page. So place an image in
there to perform the function of that text, and that text then needs
to go into the ALT. that's it.
>I coming to the conclusion that "theory" says have null "alt"
A photo with a link, should definately not have a null alt, that would
be very wrong. title is optional, personally I'd leave it out, and
title the linked resource in the A.
Jim.
Chris Morris
> In message <874r00z...@dinopsis.dur.ac.uk>, Chris Morris
> <c.i.m...@durham.ac.uk> writes
> [snip]
> > I'm not sure it is the de-facto
> >standard way precisely because it's used so little. While there's no
> >real de-facto standard, it's probably best to work out what will work
> >well for everyone.
>
> Quote from the RNIB website http://www.rnib.org.uk :
Largely agreed, though I think some of their suggested alternatives
are non-ideal, and I definitely disagree with them on choice of fonts,
etc. p { font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 80%} indeed...
> >> e.g. "Image of Chinese Soldier" ["Image Description"] "Deeee"
> >
> >Okay, now assume that the image isn't a link itself, and we're cycling
> >through the list of links.
> >
> >"Some text link" "Some text link" "Deee" "Deee" "Deee" "Deee" "Deee"
> >"Some text link"
> >
> >Not so helpful.
>
> I'm not sure I understand why you'd want to have a d-link if you've
> already got a narrative link to the description page sited next to the
Agreed, I wouldn't.
> image. Perhaps you could explain further? (give me some HTML so that I
> see what you're trying to achieve)
Sorry
<p>...<a href="...">Some text link</a>...<a href="...">Some text link</a></p>
<p>...</p>
<div><img src="..." alt="..."><a href="...">D</a></div>
<div><img src="..." alt="..."><a href="...">D</a></div>
<div><img src="..." alt="..."><a href="...">D</a></div>
<div><img src="..." alt="..."><a href="...">D</a></div>
<p>...</p>
<p>...<a href="...">Some text link</a>..</p>
was the sort of thing I was meaning. The text links not related
(directly) to the images.
--
Chris
Chris Morris
> *If* the main point of your site is your photographs (and I'm assuming from
> your original post that it is), why is accessibility for a text-only or
> text-to-speech user (so that they can read what is in the pix they can't, or
> choose not to see) more important than making your pix available to people
> (like me) with older browsers which don't read CSS but do show pictures,
> tables and frames?
It shouldn't be (equal importance). However, CSS is always supposed
to be optional. Therefore, if older browsers that don't understand
CSS get the page, it may not look as nice, but the content will still
be there.
The risk is that older browsers will mess up the CSS so much that the
page will be unreadable. A few CSS-hiding tricks like @import or
@media all may be necessary, then.
> (Apart from the solely legalistic argument)
IANAL, but I would say that failing to display in Browser X was an
accessibility problem regardless of what Browser X was. Excluding the
really ancient ones that can't handle modern HTTP, never mind anything
else.
--
Chris
Alan J. Flavell
> Imagine you weren't using images, you'd have <a href="..."> text </a>
> and that text is discussing the other page. So place an image in
> there to perform the function of that text, and that text then needs
> to go into the ALT. that's it.
Agreed. To be more specific: imagine that you weren't using thumbnail
images, but texts, to link to the full-size pictures. Choose the apt
text for that. Now replace the texts by thumbnails, and your
previously-chosen text goes into the ALT attribute.
To repeat a bit of advice I got from the WAI GL mailing list (who, by
the way, have forcibly unsubscribed me for automatically rejecting
their attempts to send me fragments of the Sobig virus):
"Think of the alt text and the images as alternative
representations of the content".
Oh well, I don't have enough time for active participation in that
list at the moment anyway.
> >I coming to the conclusion that "theory" says have null "alt"
>
> A photo with a link, should definately not have a null alt, that would
> be very wrong.
A null alt text, when an image is the only thing inside of a link,
will rightly trigger an accessibility alert. If the image is
accompanied by text within the same link, however, alt="" or alt=" "
are acceptable, and indeed there's an example in the WAI techniques
document (which Bobby incorrectly flags as an error - they emailed me
months ago in response to my bug report, agreeing that this was a
fault, and that they intended to fix it, but their online tester
*still* wrongly flags this situation).
> title is optional, personally I'd leave it out, and
> title the linked resource in the A.
This is an interesting nicety. The title attribute is supposed to
contain auxiliary information about the element to which it's applied.
So *in theory* the img title (for a thumbnail) should, it seems, tell
more about the thumbnail, whereas the title= on the "a href=" should
tell more about what lies at the destination of the link. But I
wouldn't try to assert that theory too strongly, and few browsers will
(at least without add-ons such as scripted DOM thingies) offer to
display all three of the alt text and the two title texts, if the
scope of the two elements co-incides. (*Overlapping* elements with
differing title texts are fine, on the other hand).
Alan J. Flavell
> > Quote from the RNIB website http://www.rnib.org.uk :
>
> Largely agreed, though I think some of their suggested alternatives
> are non-ideal, and I definitely disagree with them on choice of fonts,
> etc. p { font-family: Verdana, Arial, Helvetica, sans-serif;
> font-size: 80%} indeed...
Best viewed by the totally blind, indeed. :-(
Btw, any comments (positive or negative, I'm open to either) on the
technique shown in this rather old page of mine (and maybe comments on
how to update it for present good-practice)?
http://ppewww.ph.gla.ac.uk/~flavell/alt/floater.html
Liz
Chris Morris <c.i.m...@durham.ac.uk> wrote:
> Liz <l...@v-liz.co.uk> writes:
> > *If* the main point of your site is your photographs (and I'm assuming from
> > your original post that it is), why is accessibility for a text-only or
> > text-to-speech user (so that they can read what is in the pix they can't, or
> > choose not to see) more important than making your pix available to people
> > (like me) with older browsers which don't read CSS but do show pictures,
> > tables and frames?
>
> It shouldn't be (equal importance).
But if the main, or only point of a site is the pictures, why should
non-graphical browsers even have to be considered? So that people can read
titles and alt-texts of pix they can't see? What on earth's the point of that?
I can see if someone is choosing to browse with graphics off, then they
might see that there is a pic of a Sallylightfoot Crab, which they want to
see, whack graphics on and refresh the page, but obviously not if they're
using Lynx. (I'm talking of album or portfolio type pages, where the only
text is informative of the picture, the picture isn't illustrating the
text).
I don't even think the above scenario is very likely. If somone wants to see
a pic of a SLF Crab, they'd probably have done a search for it, and be
browsing with graphics on.
It would be different if the page was a scientific treatise on crabs, with a
few illustrations thrown in.
Jim Ley
>I can see if someone is choosing to browse with graphics off, then they
>might see that there is a pic of a Sallylightfoot Crab, which they want to
>see, whack graphics on and refresh the page, but obviously not if they're
>using Lynx. (I'm talking of album or portfolio type pages, where the only
>text is informative of the picture, the picture isn't illustrating the
>text).
There's lots of reasons why people are in situations without images,
but want to see certain images, consider sitting in the pub paying
lots for your GPRS connection trying to answer the pub quiz question
about the colour of the feelers on a Sallylightfoot Crab (The
pictures really are stunning btw, I really wish my wildlife
photography attempts got close to yours and Barrys)
>I don't even think the above scenario is very likely. If somone wants to see
>a pic of a SLF Crab, they'd probably have done a search for it, and be
>browsing with graphics on.
The use of the ALT and the link text to contain the crabs name is more
likely to get the person searching for a picture of it to the right
place. A photo gallery of mine that I did ages ago as a test of
trying to do one accessibily gets lots of hits from people looking for
images of geese and swans.
Jim.
Andreas Prilop
> But if the main, or only point of a site is the pictures, why should
> non-graphical browsers even have to be considered? So that people can read
> titles and alt-texts of pix they can't see? What on earth's the point of that?
http://images.google.com/images?q=%22sally+lightfoot+crab%22
Barry Pearson
> This is an interesting nicety. The title attribute is supposed to
> contain auxiliary information about the element to which it's applied.
> So *in theory* the img title (for a thumbnail) should, it seems, tell
> more about the thumbnail, whereas the title= on the "a href=" should
> tell more about what lies at the destination of the link. But I
> wouldn't try to assert that theory too strongly, and few browsers will
> (at least without add-ons such as scripted DOM thingies) offer to
> display all three of the alt text and the two title texts, if the
> scope of the two elements co-incides. (*Overlapping* elements with
> differing title texts are fine, on the other hand).
Since starting this thread, I've seen lots of good advice. I've also been
trying the IBM "Home Page Reader" (HPR). I've now come the following
conclusion about thumbnails that provide a link to the full-size photograph.
The thumbnail is rather like a button, but with more clues about what is being
linked to. Therefore, more information is lost, and needs an alternative, if
it isn't displayed. Also - strictly speaking I believe the "alt" text isn't
actually there to provide a tooltip. So:
The "title" for the thumbnail should be whatever you would put as the "title"
for a "yellow ball" button that provided the same link, in order to give a
good tooltip. I won't say what that is at the moment, but see below.
The "alt" for the thumbnail should identify the "more clues" that the
thumbnail provides compared with a "yellow ball" button. (This may be the same
as the "title" or different, see below).
That is, I think, "logically" correct. But in the present company, that is a
dangerous statement to make!
The IBM HPR doesn't read "title" text. (Or if it can be made to do so, I don't
know how). Instead it reads the "alt" text for a thumbnail. If this is
representative of readers, I have to either supply non-null "alt" for
thumbnails or an accompanying equivalent text link. But I've found that some
information I can tolerate as a tooltip is irritating when it is spoken out.
It is easier to ignore the last half of a tooltip than the last half of a
spoken sentence.
I've therefore just gone through my galleries ensuring that all the thumbnails
have both "alt" and "title" text. The "title" text is typically a subset of
what is on the target photograph page, most important part first,
somewhat-useful but not absolutely necessary part last. The "alt" text is
typically a subset of "title", concentrating on the important part that
someone using accessibility technology really does need to make a decision
whether to follow the link. (At which point the extra information will be
present on the page, of course).
I've put both into the "img" tag. If I put the "title" into the "a" tag and
the "alt" into the "img" tag, the IE6 tooltip is the "alt", and the "title"
gets ignored. (Hm! Am I coding for a specific browser? Mozilla Firebird
displays the "title" in the "a" tag as a tooltip, which may well be right!)
Example:
<a href="../pictures/eg95/eg95_22_23_3.htm">
<img src="../pictures/eg95/eg95_22_23_0.jpg" width="125" height="67"
alt="Sally Lightfoot Crab"
title="Sally Lightfoot Crab, Grapsus grapsus" border="0">
</a>
Tooltip by IE6 & Mozilla Firebird beta: Sally Lightfoot Crab, Grapsus grapsus
Spoken by IBM HPR: Sally Lightfoot Crab
http://www.barry.pearson.name/photography/portfolios/ecuador.htm
(Note for "jake" - I haven't sorted out the tabbing in that gallery yet).
There are still some compromises there. But that is inevitable - there is no
algorithm which is guaranteed to give an exact, repeatable, answer. It comes
down to "what do I think a sighted person wants/needs, and what do I think a
visually-impaired person wants/needs". And no two people are alike.
Barry Pearson
> contain auxiliary information about the element to which it's applied.
> So *in theory* the img title (for a thumbnail) should, it seems, tell
> more about the thumbnail, whereas the title= on the "a href=" should
> tell more about what lies at the destination of the link. But I
> wouldn't try to assert that theory too strongly, and few browsers will
> (at least without add-ons such as scripted DOM thingies) offer to
> display all three of the alt text and the two title texts, if the
> scope of the two elements co-incides. (*Overlapping* elements with
> differing title texts are fine, on the other hand).
Since starting this thread, I've seen lots of good advice. I've also been
Example:
http://www.barry.pearson.name/photography/portfolios/ecuador.htm
--
Barry Pearson
http://www.Barry.Pearson.name/photography/
Barry Pearson
> contain auxiliary information about the element to which it's applied.
> So *in theory* the img title (for a thumbnail) should, it seems, tell
> more about the thumbnail, whereas the title= on the "a href=" should
> tell more about what lies at the destination of the link. But I
> wouldn't try to assert that theory too strongly, and few browsers will
> (at least without add-ons such as scripted DOM thingies) offer to
> display all three of the alt text and the two title texts, if the
> scope of the two elements co-incides. (*Overlapping* elements with
> differing title texts are fine, on the other hand).
Since starting this thread, I've seen lots of good advice. I've also been
Example:
http://www.barry.pearson.name/photography/portfolios/ecuador.htm
--
Barry Pearson
http://www.Barry.Pearson.name/photography/
Liz
j...@jibbering.com (Jim Ley) wrote:
> On Sat, 30 Aug 2003 14:54:06 +0100, Liz <l...@v-liz.co.uk> wrote:
>
> >I can see if someone is choosing to browse with graphics off, then they
> >might see that there is a pic of a Sallylightfoot Crab, which they want to
> >see, whack graphics on and refresh the page, but obviously not if they're
> >using Lynx. (I'm talking of album or portfolio type pages, where the only
> >text is informative of the picture, the picture isn't illustrating the
> >text).
>
> There's lots of reasons why people are in situations without images,
> but want to see certain images, consider sitting in the pub paying
> lots for your GPRS connection trying to answer the pub quiz question
> about the colour of the feelers on a Sallylightfoot Crab
Oooooh - that's CHEATING ;-)
> (The pictures really are stunning btw,
Oh yes. I like the crab and the iguanas and the Frigatebird especially, but
they're all fantastic.
Get over to rec.photo.nature, Barry, so's I can ask you about the Galapagos!
Slainte
Isofarro
> *If* the main point of your site is your photographs (and I'm assuming
> from your original post that it is), why is accessibility for a text-only
> or text-to-speech user (so that they can read what is in the pix they
> can't, or choose not to see) more important than making your pix available
> to people (like me) with older browsers which don't read CSS but do show
> pictures, tables and frames?
Your browser not supporting CSS is not an accessibility problem - it does
not prevent you from accessing the content.
--
Iso.
FAQs: http://html-faq.com http://alt-html.org http://allmyfaqs.com/
Recommended Hosting: http://www.affordablehost.com/
Web Standards: http://www.webstandards.org/
Chris Morris
> I can see if someone is choosing to browse with graphics off, then they
> might see that there is a pic of a Sallylightfoot Crab, which they want to
> see, whack graphics on and refresh the page, but obviously not if they're
> using Lynx. (I'm talking of album or portfolio type pages, where the only
> text is informative of the picture, the picture isn't illustrating the
> text).
I have a habit of using a text-browser (w3m rather than lynx) a fair
bit in an X-windows system. It's set up so I can, if I think (from
the alt or context) an image is likely to be interesting, with a
single key, open it in ImageMagick's 'display' program.
--
Chris
Barry Pearson
> In message <4o_3b.234$Ic6....@newsfep2-gui.server.ntli.net>
> "Barry Pearson" <ne...@childsupportanalysis.co.uk> wrote:
> > Chuckle! I've had to give up on users of early NNs. The more
> > style-information I push into CSSs, the worse I make things for early
> > browsers. Tough.
> >
> I must be particularly dense on this point.
> This is where the whole accessibility thing has me totally bamboozled.
> Still.
>
> *If* the main point of your site is your photographs (and I'm assuming
> from your original post that it is), why is accessibility for a text-only
> or text-to-speech user (so that they can read what is in the pix they
> can't, or choose not to see) more important than making your pix
> available to people (like me) with older browsers which don't read CSS
> but do show pictures,
> tables and frames? (Apart from the solely legalistic argument)
Good question. It's a compromise with various components. Whatever decisions I
make about where to spend my time loses me part of my potential audience!
(There is no legal requirement in my case - these are unofficial web sites).
1. The argument about using CSSs is completely separate from the discussion
here about text for thumbnails. I started to move from no CSSs towards
considerable use of CSSs last October for one of my web sites. I've steadily
converted all of my web sites since. It is starting to give me the combination
of flexibility, efficiency, and presentation I want. It also makes some of my
pages smaller and faster to download. For example I used to use GIF buttons &
javascript for roll-over buttons. Now I use styles.
I can leave lots of decisions until later, then refine the presentation with
advice from others. I don't have an "instinctive feel" for web page design, so
I put as many decisions as I can into a style sheet, then just experiment with
the style sheet until the site looks OK. (Except for my photograph pages, I
think I would prefer to "outsource" the development of the CSS to someone who
knew what they were doing, while I concentrated on the content).
2. Part of the answer to your question is that it is easier to upgrade a
browser than it is to upgrade a pair of eyes. You may have a good reason to
use an older browser. But I've talked to people who have had problems with my
web sites and it has turned out that they could have reconfigured their
monitors to a larger size instead of using the defaults. I obviously can't
insist that people adapt to their configurations just to look at my web sites!
I never say "this web site looks best with XYZ browser". But if a range of
modern browsers on a range of platforms can present my web sites
satisfactorily, I treat the problems of people with older browsers as lower
priority. (Sorry!)
3. Although accessibility was ONE of the reasons for this thread, it wasn't
the only one. I simply wanted a set of guidelines for how to code thumbnail
galleries that would have maximum applicability and longevity. There may be a
way of coding thumbnail galleries that, if everyone did it, would make the web
a better place for lots of people. What is it?
I wondered if there were such guidelines already. I now suspect there are not.
Otherwise people here may have pointed me at them.
4. An important question behind your questions is: "why do people with
impaired vision want/need to look at photograph galleries and photographs
anyway?"
This puzzled me when someone first suggested that I make my photography
section more accessible. When I print a photograph and stick it on the wall,
you had better be of normal height and have decent eyesight, else you may not
see it. If I project it, you had better not be afraid of the dark, because I
don't compromise the viewing environment. But ... I am told that people with
limited vision do indeed get something out of looking at photographs. And this
is particularly so when the photograph is accompanied by explanatory material.
So ... I go with the flow. I'm looking for some simple low-cost principles
that will enable me to display my photographs on the web and also enable such
people to appreciate them. I don't want to spend lots of extra effort for each
sub-group. I would rather have an approach which worked for all of them by
default. (I'm lazy!)
There is a considerable overlap between the problems of people with poor
vision, other handicaps, slow dial-up lines, small screens, poor screen colour
resolution, etc. I just want the magic answer which will enable me then to
ignore all those viewer-problems!
Chris Morris
> Btw, any comments (positive or negative, I'm open to either) on the
> technique shown in this rather old page of mine (and maybe comments on
> how to update it for present good-practice)?
> http://ppewww.ph.gla.ac.uk/~flavell/alt/floater.html
I like the idea. Wish I'd known about it sooner, there's been times
it would have been a useful way around making an image a link without
putting an ugly border on it.
In certain cases it might be possible to absolutely position rather
than float the image, though I can't see many uses for that. Maybe to
get a set of icons down the left, like
http://www.dur.ac.uk/c.i.morris/icon.html to re-implement <link> or
similar for non-supporting browsers. More a 'this is possible' than
an actual good idea, I suspect.
Can't think of a sensible solution to the 'D-link' issue that wouldn't
be very confusing for text browser users, and for that matter I'm not
sure how browsers would react to something with alt="" and a longdesc.
Don't have a speech browser around to test it on either.
--
Chris
Liz
Isofarro <spam...@spamdetector.co.uk> wrote:
> Liz wrote:
>
> > *If* the main point of your site is your photographs (and I'm assuming
> > from your original post that it is), why is accessibility for a text-only
> > or text-to-speech user (so that they can read what is in the pix they
> > can't, or choose not to see) more important than making your pix available
> > to people (like me) with older browsers which don't read CSS but do show
> > pictures, tables and frames?
>
> Your browser not supporting CSS is not an accessibility problem - it does
> not prevent you from accessing the content.
Assuming that you regard the content as only being the text.
I have seen totally CSS sites where I can't see the images, and there are,
as I said, sites where the content *is* the images. Of course, the CSS may
have been faulty, I couldn't possibly say.
Liz
"Barry Pearson" <ne...@childsupportanalysis.co.uk> wrote:
> 2. Part of the answer to your question is that it is easier to upgrade a
> browser than it is to upgrade a pair of eyes. You may have a good reason to
> use an older browser. But I've talked to people who have had problems with my
> web sites and it has turned out that they could have reconfigured their
> monitors to a larger size instead of using the defaults. I obviously can't
> insist that people adapt to their configurations just to look at my web sites!
> I never say "this web site looks best with XYZ browser". But if a range of
> modern browsers on a range of platforms can present my web sites
> satisfactorily, I treat the problems of people with older browsers as lower
> priority. (Sorry!)
I can see *your* site very well (as it is at the moment) - it looks great.
I wasn't arguing with you but with 'principles'.
I think what you're saying is perfectly true, each web author has to aim for
a target audience.
I'd think when most people design websites, they have a 'typical audience'
in mind, and if people choose not to tie themselves in knots over people
using web access in cars, or who want to cheat in pub quizzes, it's up to
them. Of course, that's already the case for personal sites, but for many
commercial sites, it should also be the case - exactly like shops design for
a 'target' clientele, even if that puts off other demographics, to whom
their goods are marginally relevant. It's not to say that sites should be
made unaccessible or that serious efforts shouldn't be made towards
accessibility, but ultimately if your target audience is teenage boy
skateboarders, attracting and holding them is more important than
accessibility to their grandparents (I know you're going to point out their
gps might buy them prezzies from the site: but just like the shops the gps
wouldn't like to go into, they could give them the money to spend at the
site.)
Depends, of course, on the purpose of the site.
Conversely, few of the worthily accessible sites will attract or retain many
teenage boys. Horses for courses.
I'm not against accessibility. It's just not the be-all and end-all.
Last week I had a page which passed w3c, but I hadn't noticed I'd forgotten
to put a .jpg on the end of two images on the page (RiscOS doesn't need it,
and Fresco shows up pages without it.) Another page showed up
fine on Fresco at 800x600, fine in IE at high resolution, validated at w3c,
but was 'all over the place' in IE at 800x600. The content was all there (if
you scrolled horizontally over a space!), but IMO that's not the only thing
which matters.
King Queen
>The use of the ALT and the link text to contain the crabs name is more
>likely to get the person searching for a picture of it to the right
>place.
Indeed, it's the main way that the Google image search indexes images.
--
King Queen - Remove .lartsspammers to reply. http://www.kingqueen.org.uk
"We need to love and respect the Earth with the same intensity that we
give to our families and our tribe ................. for we are a part
of it". - James Lovelock
Barry Pearson
[snip]
> There's lots of reasons why people are in situations without images,
> but want to see certain images, consider sitting in the pub paying
> lots for your GPRS connection trying to answer the pub quiz question
> about the colour of the feelers on a Sallylightfoot Crab (The
> pictures really are stunning btw, I really wish my wildlife
> photography attempts got close to yours and Barrys)
Thanks, Jim!
I was born with 2 left-brains. Numbers, algorithms, logic, etc, are fun.
Artistic endeavours are so far beyond me that they are out of sight.
But for some reason I can take photographs that many people enjoy looking at.
They are NOT creative. I can't pose people, for example. (I have to ask them
to pose themselves). I call them "selective". I subject a scene to my
analytical abilities, select key features, capture them, then present them,
stripped of clutter. Many people like to see photographs stripped of clutter.
Because I can't pose people, I treat the subject as a peer, not an "employee".
Whether they are people or animals, I try to interact with them at the same
level. So some of my wildlife pictures are "portraits", with eyeball to
eyeball contact. Many people like this effect, and I hope the animals would
too if they had brains capable of expressing an opinion.
[snip]
> The use of the ALT and the link text to contain the crabs name is more
> likely to get the person searching for a picture of it to the right
> place. A photo gallery of mine that I did ages ago as a test of
> trying to do one accessibily gets lots of hits from people looking for
> images of geese and swans.
Yes. My experience is that some people find my photographs by searching using
the scientific name. So I ensure that this is in the page's Title, the "alt"
text for the image, and the surrounding text.
My new web site has pre-configured searches based on the scientific name, for
each of the photographs within it. See:
http://www.birdsandanimals.info/galleries.htm
--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
Jim Ley
<kq.larts...@kingqueen.org.uk> wrote:
>On Sat, 30 Aug 2003 14:11:37 GMT, j...@jibbering.com (Jim Ley) wrote:
>
>>The use of the ALT and the link text to contain the crabs name is more
>>likely to get the person searching for a picture of it to the right
>>place.
>
>Indeed, it's the main way that the Google image search indexes images.
It's one of the ways, there are others. For example the link text in
a link to the image.
Jim.
Jim Ley
>Conversely, few of the worthily accessible sites will attract or retain many
>teenage boys. Horses for courses.
Why on earth not, you seem to be confusing accessibility with a
certain look which is simply not a sustainable position, and not one
that anyone I know of supports. The WAI WCAG certainly does not say
this, and neither does any other documentation I've seen.
>
>I'm not against accessibility. It's just not the be-all and end-all.
>Last week I had a page which passed w3c
So it was syntactically valid HTML, that's only a tiny part of web
authoring QA, it's also almost nothing to do with accessibility.
>, but I hadn't noticed I'd forgotten
>to put a .jpg on the end of two images on the page (RiscOS doesn't need it,
>and Fresco shows up pages without it.)
Automated QA would be around to deal with these, but a validator, or
even a syntax linter that v.w3.org is (controversially) becoming would
be able to catch that. Something along the lines of the link checker
should, in fact I've often wondered why it doesn't already.
> Another page showed up
>fine on Fresco at 800x600, fine in IE at high resolution, validated at w3c,
>but was 'all over the place' in IE at 800x600.
Again, no fully automated system is likely to manage this, although if
you use CSS, the CSS validator is going to have a better chance than
anything else.
> The content was all there (if
>you scrolled horizontally over a space!), but IMO that's not the only thing
>which matters.
Of course it isn't, and poorly designed will likely not be very
accessible either, accessibility is not making everything plain text.
Jim.
jake
>jake <ja...@gododdin.demon.co.uk> writes:
>> In message <874r00z...@dinopsis.dur.ac.uk>, Chris Morris
>> <c.i.m...@durham.ac.uk> writes
>> [snip]
>> > I'm not sure it is the de-facto
>> >standard way precisely because it's used so little. While there's no
>> >real de-facto standard, it's probably best to work out what will work
>> >well for everyone.
>>
>> Quote from the RNIB website http://www.rnib.org.uk :
>
>Largely agreed, though I think some of their suggested alternatives
>are non-ideal, and I definitely disagree with them on choice of fonts,
>etc. p { font-family: Verdana, Arial, Helvetica, sans-serif;
>font-size: 80%} indeed...
Yes. Strange indeed ... especially Verdana. I've noticed that Trebuchet
seems to be the sans-serif font of choice on some 'disabilities' sites
-- with 'Georgia' the sarif'd font.
These are the two basic fonts that I would tend to use.
>
[snip]
>> Perhaps you could explain further? (give me some HTML so that I
>> see what you're trying to achieve)
>
>Sorry
><p>...<a href="...">Some text link</a>...<a href="...">Some text link</a></p>
>
><p>...</p>
>
><div><img src="..." alt="..."><a href="...">D</a></div>
><div><img src="..." alt="..."><a href="...">D</a></div>
><div><img src="..." alt="..."><a href="...">D</a></div>
><div><img src="..." alt="..."><a href="...">D</a></div>
>
><p>...</p>
>
><p>...<a href="...">Some text link</a>..</p>
>
>was the sort of thing I was meaning. The text links not related
>(directly) to the images.
>
Let me try this in HPR and report back.
regards.
--
Jake
jake
Pearson <ne...@childsupportanalysis.co.uk> writes
>jake <ja...@gododdin.demon.co.uk> wrote:
>[snip]
>
>Thanks for that. I'll experiment.
>
>Can you point me to some readers that I can try? Which are the important ones?
>
>I've just downloaded a trial version of the IBM "Home Page Reader" to get a
>feel for how they work in practice. But I don't know if that is mainstream or
>irrelevant. We are warned against designing web sites for particular browsers.
>The same should surely apply to "accessibility technology" too - but does it?
>
HPR is very much mainstream, and seems to be No. 1 in capability when it
comes to reading a page of HTML.
Other competitors (although these are multi-functional 'screen readers'
and not browsers) are JAWS and Windows Eyes.
Here's a report comparing the three :
http://www.camo.qc.ca/ntic/csun2002en.htm
There is some difference in capability between these three leading
contenders -- but not that much.
All of them still have someway to go, though.
regards.
--
Jake
Isofarro
> In message <b8mqib...@sidious.isolani.co.uk>
> Isofarro <spam...@spamdetector.co.uk> wrote:
>
>> Liz wrote:
>>
>> > *If* the main point of your site is your photographs (and I'm assuming
>> > from your original post that it is), why is accessibility for a
>> > text-only or text-to-speech user (so that they can read what is in the
>> > pix they can't, or choose not to see) more important than making your
>> > pix available to people (like me) with older browsers which don't read
>> > CSS but do show pictures, tables and frames?
>>
>> Your browser not supporting CSS is not an accessibility problem - it does
>> not prevent you from accessing the content.
>
> Assuming that you regard the content as only being the text.
Bollocks.
Isofarro
> Conversely, few of the worthily accessible sites will attract or retain
> many teenage boys.
Considering more and more kids these days seem to be suffering from dyslexia
the above statement is rather crass.
> I'm not against accessibility. It's just not the be-all and end-all.
> Last week I had a page which passed w3c,
Automated testing doesn't guarantee accessibility. It just says that for
what could be tested automatically passed those tests. Nothing more.
> but I hadn't noticed I'd
> forgotten to put a .jpg on the end of two images on the page
URLs to graphics don't require .jpg at the end. It is entirely up to the
webserver to match a requested URL to whatever resource it sends back. The
above would have been found using a link checker, not a validator, an
accessibility checker nor a css checker.
> Another page
> showed up fine on Fresco at 800x600, fine in IE at high resolution,
> validated at w3c, but was 'all over the place' in IE at 800x600.
Visual representation is not a part of validation. Validation is about
checking the document on how it complies to the HTML syntax - be it from an
SGML or XML perspective. It says whether the document is correctly formed
or not. Nothing more.
> The
> content was all there (if you scrolled horizontally over a space!), but
> IMO that's not the only thing which matters.
Better or worse than your default browser settings? (The ones you don't
like, but don't seem to change to reflect your preferences)
Liz
Isofarro <spam...@spamdetector.co.uk> wrote:
> > The
> > content was all there (if you scrolled horizontally over a space!), but
> > IMO that's not the only thing which matters.
>
>
> Better or worse than your default browser settings? (The ones you don't
> like, but don't seem to change to reflect your preferences)
When did I say I didn't like them???
Liz
> Liz wrote:
>
> > Conversely, few of the worthily accessible sites will attract or retain
> > many teenage boys.
>
> Considering more and more kids these days seem to be suffering from dyslexia
> the above statement is rather crass.
>
Which is exactly why they'd rather spend time in a flashy site (or
preferably a Flash-y) one rather than a boring one. They generally run a
mile from text-heavy ones.
A definite preference for style over content, or at least style with some
content.
Horses for courses.
Never forget the end-users.
You can be as perfectly accessible as you like, but if your target audience
is bored and leaves, never to return, your site has failed.
Interestingly, the teenage boy demographic is also a prime user of browsing on handhelds, but that would normally be different kinds of sites to the ones they visit on a regular computer - dirty joke sites seem de rigeur ATM. Of course, both technologies will continue to evolve.
Alan J. Flavell
> Isofarro <spam...@spamdetector.co.uk> wrote:
>
> > Your browser not supporting CSS is not an accessibility problem - it does
> > not prevent you from accessing the content.
>
> Assuming that you regard the content as only being the text.
This is nonsense, I'm afraid.
Stylesheets are optional, _by design_, since a stylesheet intended for
one range of browsing situations can be actively disadvantageous for
another.
If you put your "other media" (images, audio, streaming media, VRML,
whatever) into a stylesheet, and thus make them optional, then you'd
have only yourself to blame. If you link them in the ways that HTML
provides, then they're still available to anyone who's in a position
to use them. My laptop, admittedly, doesn't have VRML support, and
its support for rtsp: (streaming media) is less than ideal; but if I'm
browsing with Lynx and I'm offered an interesting image, then I'm only
a click away from opening it in a helper application.
So let's have no more of this nonsense about text-only. Might I
mention the straw-man argument collection, and in particular
http://ppewww.ph.gla.ac.uk/~flavell/www/html-smac.html#smac3 ?
It's not exactly new, and might not be the last word on the topic, but
I stand by what I say there.
> I have seen totally CSS sites where I can't see the images, and there are,
> as I said, sites where the content *is* the images. Of course, the CSS may
> have been faulty, I couldn't possibly say.
Well, I could - and so, I think, could quite a few others around here.
all the best
(and yes, lest there be any misunderstandings about it, your pics are
indeed stunning.)
Isofarro
> In message <2d1rib...@sidious.isolani.co.uk>
> Isofarro <spam...@spamdetector.co.uk> wrote:
>
>> Liz wrote:
>>
>> > Conversely, few of the worthily accessible sites will attract or retain
>> > many teenage boys.
>>
>> Considering more and more kids these days seem to be suffering from
>> dyslexia the above statement is rather crass.
>>
> Which is exactly why they'd rather spend time in a flashy site (or
> preferably a Flash-y) one rather than a boring one.
Accessibility doesn't equate to "boring one". That's a typical over-used
much refuted myth.
Isofarro
> In message <2d1rib...@sidious.isolani.co.uk>
> Isofarro <spam...@spamdetector.co.uk> wrote:
>
>
>> > The
>> > content was all there (if you scrolled horizontally over a space!), but
>> > IMO that's not the only thing which matters.
>>
>>
>> Better or worse than your default browser settings? (The ones you don't
>> like, but don't seem to change to reflect your preferences)
>
> When did I say I didn't like them???
Previously. You've often mentioned how you don't like website that present
you with Black text on a grey background - that would be your default
browser settings.
Barry Pearson
> one range of browsing situations can be actively disadvantageous for
> another.
>
> If you put your "other media" (images, audio, streaming media, VRML,
> whatever) into a stylesheet, and thus make them optional, then you'd
> have only yourself to blame. If you link them in the ways that HTML
> provides, then they're still available to anyone who's in a position
> to use them. My laptop, admittedly, doesn't have VRML support, and
> its support for rtsp: (streaming media) is less than ideal; but if I'm
> browsing with Lynx and I'm offered an interesting image, then I'm only
> a click away from opening it in a helper application.
Please clarify the principles about CSSs being optional.
I realise that, since my CSSs are concerned largely with visual matters (font
style, sizes, spacing, colour, etc) they need to be ignored/overridden by
accessibility technology for visually-impaired people. Or some people may
choose to use their own style sheet. OK.
But for people seeing my web sites in the more common way, since I started to
change my web sites from no-CSSs to largely CSS-controlled, their appearance
without CSSs has degraded massively. Yes, the content is there in the same
order, but typically squashed up, crudely-aligned, etc. To such a person the
web sites would appear to have deliberately been screwed up, and certainly
harder to read conventionally.
In other words, having made the change, I am assuming that people without such
accessibility problems will use my CSSs. And as I learn more about CSSs, I
make fewer concessions to those who could use them but don't.
Isofarro
> But for people seeing my web sites in the more common way, since I started
> to change my web sites from no-CSSs to largely CSS-controlled, their
> appearance without CSSs has degraded massively.
The presentation has degraded somewhat, since it is now presented in the
default browser rendering, instead of your suggested stylesheets.
> Yes, the content is there
> in the same order, but typically squashed up, crudely-aligned, etc. To
> such a person the web sites would appear to have deliberately been screwed
> up, and certainly harder to read conventionally.
This is where well-structured HTML comes into play. Typically, a well
structured HTML page will make still be readable without requiring a
stylesheet. It is using the stock standard browser defaults, so the end
result should always be readable.
Barry Pearson
> Barry Pearson wrote:
>
> > But for people seeing my web sites in the more common way, since I
> > started to change my web sites from no-CSSs to largely CSS-controlled,
> > their appearance without CSSs has degraded massively.
>
> The presentation has degraded somewhat, since it is now presented in the
> default browser rendering, instead of your suggested stylesheets.
But my point was that it has degraded massively compared with the time that I
didn't use style sheets. (I only started last October).
> > Yes, the content is there
> > in the same order, but typically squashed up, crudely-aligned, etc. To
> > such a person the web sites would appear to have deliberately been
> > screwed up, and certainly harder to read conventionally.
>
> This is where well-structured HTML comes into play. Typically, a well
> structured HTML page will make still be readable without requiring a
> stylesheet. It is using the stock standard browser defaults, so the end
> result should always be readable.
Yes, but badly, now. If I were producing a document for some other medium, I
would never consider even issuing a draft document that looks so crude. It
would display contempt for my readers.
There is "accessibility technology" for people with various problems with
seeing, etc. Now, CSSs are the "accessibility technology" for people who can
browse without other accessibility technology. I suppose I am saying that I
don't see why I should spend time worrying about people who don't use
presentation aids other than browser defaults.
Isofarro
> Isofarro <spam...@spamdetector.co.uk> wrote:
>> Barry Pearson wrote:
>>
>> > But for people seeing my web sites in the more common way, since I
>> > started to change my web sites from no-CSSs to largely CSS-controlled,
>> > their appearance without CSSs has degraded massively.
>>
>> The presentation has degraded somewhat, since it is now presented in the
>> default browser rendering, instead of your suggested stylesheets.
>
> But my point was that it has degraded massively compared with the time
> that I didn't use style sheets. (I only started last October).
Try comparing your pre-CSS tables based designs in browsers that don't
support tables - then tell me which has degraded the worst.
>> > Yes, the content is there
>> > in the same order, but typically squashed up, crudely-aligned, etc. To
>> > such a person the web sites would appear to have deliberately been
>> > screwed up, and certainly harder to read conventionally.
>>
>> This is where well-structured HTML comes into play. Typically, a well
>> structured HTML page will make still be readable without requiring a
>> stylesheet. It is using the stock standard browser defaults, so the end
>> result should always be readable.
>
> Yes, but badly, now.
URL? I can't really believe a well structured HTML document would be badly
readable.
> If I were producing a document for some other medium,
The Web isn't print, and has never been. Trying to impose print-based dictum
on the web only leads to lots of grief and pain.
> Now, CSSs are the "accessibility technology" for people who
> can browse without other accessibility technology.
CSS does not make your HTML more accessible. Only getting the HTML right
will get it accessible.
> I suppose I am saying
> that I don't see why I should spend time worrying about people who don't
> use presentation aids other than browser defaults.
As long as you ensure well structured, valid and accessible HTML, then you
need spend no more time about browsers with no support for CSS.
Alan J. Flavell
> Alan J. Flavell <fla...@ph.gla.ac.uk> wrote:
> [snip]
> > Stylesheets are optional, _by design_, since a stylesheet intended for
> > one range of browsing situations can be actively disadvantageous for
> > another.
[...]
> Please clarify the principles about CSSs being optional.
I think the intentions of the CSS designers are rather clear from the
fact that they defined the facility for _user_ stylesheets, and
provided the possibility for the user styles to overrule the author
styles. (The latter point was a deliberate change from an earlier CSS
specification).
> I realise that, since my CSSs are concerned largely with visual matters (font
> style, sizes, spacing, colour, etc) they need to be ignored/overridden by
> accessibility technology for visually-impaired people. Or some people may
> choose to use their own style sheet. OK.
So, I think you provided your own answer.
In a conceptual sense, the browser's default presentation is a kind of
base stylesheet.
> But for people seeing my web sites in the more common way,
... would for the most part probably choose to use your stylesheet,
but, in the final analysis, your CSS is no more than a proposal -
which they can, in principle, ignore or overrule, for whatever reasons
of their own. That's only one click away in Opera, for example.
> since I started to
> change my web sites from no-CSSs to largely CSS-controlled,
It's probably better not to use the word "control" in this sense.
As I say, your stylesheet is a proposal, not a mandate.
> their appearance without CSSs has degraded massively.
They get the default presentation of their browser. If that's bad,
then you know where to put the blame. Provided that the HTML is OK
(not just syntactically, but semantically, I mean.)
> Yes, the content is there in the same
> order, but typically squashed up, crudely-aligned, etc.
Could be that there's something wrong with the HTML, then.
> To such a person the web sites would appear to have deliberately
> been screwed up, and certainly harder to read conventionally.
For sure I adjust my browsers so that their default presentation is
usable, even if it's not exactly awe-inspiring. If a site design goes
badly wrong (in terms of getting access to the information - it isn't
going to be the height of visual excellence, sure) without
stylesheets, then I'd want to re-work it.
> In other words, having made the change, I am assuming that people
> without such accessibility problems will use my CSSs. And as I learn
> more about CSSs, I make fewer concessions to those who could use
> them but don't.
I'm not asking for "concessions", I'm asking for web-oriented design:
content and structure in HTML, with desirable-but-ultimately-optional
presentation proposals in CSS.
all the best
Liz
"Alan J. Flavell" <fla...@ph.gla.ac.uk> wrote:
> On Sat, 30 Aug 2003, Liz wrote:
>
> > Isofarro <spam...@spamdetector.co.uk> wrote:
> >
> > > Your browser not supporting CSS is not an accessibility problem - it does
> > > not prevent you from accessing the content.
> >
> > Assuming that you regard the content as only being the text.
>
> This is nonsense, I'm afraid.
[big snip]
> (and yes, lest there be any misunderstandings about it, your pics are
> indeed stunning.)
Nah, that's Barry's.
Liz
Isofarro <spam...@spamdetector.co.uk> wrote:
> Liz wrote:
>
> > In message <2d1rib...@sidious.isolani.co.uk>
> > Isofarro <spam...@spamdetector.co.uk> wrote:
> >
> >
> >> > The
> >> > content was all there (if you scrolled horizontally over a space!), but
> >> > IMO that's not the only thing which matters.
> >>
> >>
> >> Better or worse than your default browser settings? (The ones you don't
> >> like, but don't seem to change to reflect your preferences)
> >
> > When did I say I didn't like them???
>
> Previously. You've often mentioned how you don't like website that present
> you with Black text on a grey background - that would be your default
> browser settings.
>
What I meant was I didn't like visually-boring unformatted long lines of text.
It wouldn't matter if the colours were teal and rose.
Isofarro
> In message <53fsib...@sidious.isolani.co.uk>
> Isofarro <spam...@spamdetector.co.uk> wrote:
>
>> Liz wrote:
>>
>> > In message <2d1rib...@sidious.isolani.co.uk>
>> > Isofarro <spam...@spamdetector.co.uk> wrote:
>> >
>> >
>> >> > The
>> >> > content was all there (if you scrolled horizontally over a space!),
>> >> > but IMO that's not the only thing which matters.
>> >>
>> >>
>> >> Better or worse than your default browser settings? (The ones you
>> >> don't like, but don't seem to change to reflect your preferences)
>> >
>> > When did I say I didn't like them???
>>
>> Previously. You've often mentioned how you don't like website that
>> present you with Black text on a grey background - that would be your
>> default browser settings.
>>
> What I meant was I didn't like visually-boring unformatted long lines of
> text. It wouldn't matter if the colours were teal and rose.
Setting those colours up as your default browser colours will certainly help
pages not "matter" for you. Sorta like pain avoidance: It hurts when I do
this. Well don't do this.
Liz
Isofarro <spam...@spamdetector.co.uk> wrote:
> Accessibility doesn't equate to 2boringone".
> That's a typical over-used, much refuted myth.
Maybe so, but the site which has been flaunted here and in other places as
being a paragon of css (csszengarden) is boring *and* irritating here.
I am slightly tempted to have a look at it in IE, to see what all the fuss is
about, but that's hardly the point - even some FrontPage pages look good in
IE.
Liz
Isofarro <spam...@spamdetector.co.uk> wrote:
> Liz wrote:
> > What I meant was I didn't like visually-boring unformatted long lines of
> > text. It wouldn't matter if the colours were teal and rose.
> Setting those colours up as your default browser colours will certainly help
> pages not "matter" for you. Sorta like pain avoidance: It hurts when I do
> this. Well don't do this.
I thought I'd entered a parallel universe when I read this, but then I saw
that your mindset is so far from mine that you have misinterpreted what I
said.
What I meant was I don't like visually-boring, unformatted, long lines of text.
(actually I *said* that, so my meaning *should* have been clear)
Although I am so boringly Nineties as to like teal and rose, even if I set
them as my defaults, and set my font size to give me eight words per line,
I'd still bounce straight off sites which present me with all text.
I'm the visitor, it's my call; it's the designer's job to attract and hold
my interest.
It may be that in the whole world, only my husband, my sister, some friends
and colleagues I have straw-polled and I feel like this (I realise it's a
limited demographic), but that's how it is. Maybe it's something in our
water. :-/
Jim Ley
>I'd still bounce straight off sites which present me with all text.
Please stop repeating this as if anyone disagrees with you, an all
text site aswell as being boring is considerably less accessible than
others. No-one is disagreeing with you.
Jim.
Don Aitken
Well, just to liven things up, I disagree. When I visit a website,
what I am after is information, and almost always information conveyed
in the form of words. The sites I will "bounce off" are those which
place unnecessary obstacles in the way, created by people who think
that text is "visually boring". The web can be used to convey other
forms of information, of course, but text is text, and there is
nothing to be gained by trying to make it look prettier.
--
Don Aitken
Liz
j...@jibbering.com (Jim Ley) wrote:
Other than Isofarro.
But you're right.
I'll KF Isofarro, s/he can KF me, and we can both untwist our knickers.
Sorry.
Chris Morris
> In message <30fsib...@sidious.isolani.co.uk>
> Isofarro <spam...@spamdetector.co.uk> wrote:
>
> > Accessibility doesn't equate to 2boringone".
> > That's a typical over-used, much refuted myth.
>
> Maybe so, but the site which has been flaunted here and in other places as
> being a paragon of css (csszengarden) is boring *and* irritating here.
csszengarden's main purpose, I think, is to show that CSS really does
allow separation of layout and content. I'm not a great fan of most
of the actual _designs_ myself, but the principle illustrated is good.
--
Chris
Barry Pearson
> On Sun, 31 Aug 2003, Barry Pearson wrote:
> > Alan J. Flavell <fla...@ph.gla.ac.uk> wrote:
[snip]
> > Yes, the content is there in the same
> > order, but typically squashed up, crudely-aligned, etc.
>
> Could be that there's something wrong with the HTML, then.
I won't respond to all the points, since to some extent we are on the same
wavelength. I worked on computer systems architecture for quite a time, and
understand the importance of separating out the areas of concern via clean
interfaces. Then "domain experts" (and the viewer counts as a domain expert
for his/her own viewing preferences) can work independently.
Here is an example of what I mean by my statement above. In the 2nd one I
simply deleted the statement linking to the CSS.
http://www.barry.pearson.name/photography/pictures/butterflies/bf01_01_37_3.htm
http://www.barry.pearson.name/photography/temp/bf01_01_37_3.htm
It is arguable whether I should have used tables at all. For the photograph I
don't - I use nested DIVs for simple HTML with maximum flexibility in the CSS.
I use a table for the description because I wanted a "rectilinear"
question-answer approach. But that isn't the real point here.
The centre alignment, and the spacing of the elements down the page, is in the
CSS. So is the cell padding. A year ago the same photograph was laid out by
page-level tables, and didn't use a CSS. Now, without a CSS, I don't feel it
represents my photography, which is also about the presentation of
photographs, not just the images themselves.
Note also that the text has now become "syntaxtically incorrect" in a sense.
Rightly or wrongly I put the species name into italics by means of a style,
not by <i>. Yet, world wide, the convention is to use italics for species
names. Not "emphasis", not class="species", but italics. I could argue that I
went too far in this case.
I'll obviously continue to put the visual representation I want into CSSs, and
as little as possible in the HTML. But just as unsighted people need something
powerful to turn the raw HTML into something satisfying, so, I believe, do
sighted people. In a pedantic sense, the CSS is optional here. But the web
must surely be getting worse all the time for sighted people who don't, or
can't, use them.
Richard Watson
> In message <30fsib...@sidious.isolani.co.uk>
> Isofarro <spam...@spamdetector.co.uk> wrote:
>
>> Accessibility doesn't equate to 2boringone".
>> That's a typical over-used, much refuted myth.
>
> Maybe so, but the site which has been flaunted here and in other places as
> being a paragon of css (csszengarden) is boring *and* irritating here.
> I am slightly tempted to have a look at it in IE, to see what all the fuss is
> about, but that's hardly the point - even some FrontPage pages look good in
> IE.
I think it's highly likely that there will be a time (not so far down
the road) where all available browsers will support CSS far better
than deprecated markup.
The current situation is just handover between two technologies,
clearly if you insist on using the old technology you're not going to
benefit from the new.
--
Richard Watson
http://www.opencolo.com/
High Quality, Value for money colocation
Jim Ley
>In message <30fsib...@sidious.isolani.co.uk>
> Isofarro <spam...@spamdetector.co.uk> wrote:
>
>> Accessibility doesn't equate to 2boringone".
>> That's a typical over-used, much refuted myth.
>
>Maybe so, but the site which has been flaunted here and in other places as
>being a paragon of css (csszengarden) is boring *and* irritating here.
I find it the same, and I see the designs, I've yet to see one of the
designs to my taste, the markup is also rather contrived with extra
DIV's etc which shouldn't be there, has some things like:
<span class="accesskey">R</span>esources</a>
which harms machine translation.
then there's hackery like:
<script type="text/javascript"></script>
It's not even valid to be served as text/html which is a shame for a
site which is being held up as an example of good behaviour.
I wouldn't worry much by missing csszengarden.
Jim.
Jim Ley
<ne...@childsupportanalysis.co.uk> wrote:
>Note also that the text has now become "syntaxtically incorrect" in a sense.
>Rightly or wrongly I put the species name into italics by means of a style,
>not by <i>. Yet, world wide, the convention is to use italics for species
>names. Not "emphasis", not class="species", but italics. I could argue that I
>went too far in this case.
I would definately say you did, species name should be in italics.
Jim.
Richard Watson
> I wouldn't worry much by missing csszengarden.
I think it's valid as a way to showcase what can be done with CSS,
rather than what's actually useful, just as most people don't buy
vehicles at the Geneva Motor show but like to see what some designer
has created.
Barry Pearson
> "Barry Pearson" <ne...@childsupportanalysis.co.uk> writes:
> > > <img src="photo.jpg" alt="Photo:"><a href="longdesc.html">Ducks in the
> > > pond</a> CSS-styled so that the <a> is a caption for the image where
> > > appropriate.
> > > or similar. I don't think <a href="...">D</a> is anything like widely
> > > used enough to be a recognised convention.
> >
> > How do I "CSS-style so that the <a> is a caption for the image"? Is
> > this some specific feature of CSSs?
>
> <div class="thumbnail">
> <img ...>
> <a ...>...</a>
> </div>
OK, thanks, I see what you mean.
I use DIVs for supplying the target photographs, but I use tables for
supplying the thumbnails. The reason is that I design my galleries in terms of
rows-of-5, very deliberately indeed. I want the centres of the thumbnails to
form a regular grid. See the gallery below for an example of this, based on
the design of the original panels of 50cm by 40cm mounted prints. Even on the
web, I want to present my photographs as formally as I would if they were to
be judged.
http://www.barry.pearson.name/photography/portfolios/lrps.htm
Also, in my new web site (launched properly today, see below) I only supply
one size of photograph, so I get rid of the clutter of text links and just
have thumbnail links. (I have put "tabindex="1" into all the thumbnail IMG
elements to try to overcome some of the problems "jake" found with navigating
around galleries using a reader, but unfortunately the IBM Home Page Reader
doesn't appear to obey the rules for "tabindex", which state that tab should
visit those with a positive number before visiting elements without a
tabindex. HPR tabs through the buttons at the top of the page before tabbing
through the thumbnails. Perhaps I've read the rules wrong).
http://www.birdsandanimals.info/bcp/galleries/pelicans.htm
[snip]
> > Given that I want tooltips for my thumbnails, I intend to have
> > "title" text in the "img" tag in the thumbnail galleries. In that
> > case, will the speech browser speak the "title" text? If so, I was
> > thinking of having alt="" because there is then no need for
> > additional text.
>
> Speech browsers will speak the alt and _may_ speak the title
> (generally don't, I've found, but you might be able to reconfigure).
> You can't rely on title being displayed, anyway.
[snip]
IBM's HPR doesn't speak the title. I have now put both alt & title text into
my thumbnails, with the alt text being just the decision-making essentials
while the title text also has "nice to know" (eg. scientific names). IE6 and
Mozilla Firebird (beta) both show the title as tooltips.
Thanks.
(Interesting ethical issue: I have HPR on time-limited trial knowing I will
never buy it. I'm not using it to trial the product - I am using it as a
training course in accessibility. Hm!)
Jim Ley
<ne...@childsupportanalysis.co.uk> wrote:
>I use DIVs for supplying the target photographs, but I use tables for
>supplying the thumbnails. The reason is that I design my galleries in terms of
>rows-of-5, very deliberately indeed.
You have a table of photo's, a table is wholly appropriate markup
here, it contains more information than any DIV based approach.
>IBM's HPR doesn't speak the title. I have now put both alt & title text into
>my thumbnails, with the alt text being just the decision-making essentials
>while the title text also has "nice to know" (eg. scientific names). IE6 and
>Mozilla Firebird (beta) both show the title as tooltips.
Excellent, although you seem to be suggesting that you're doing it
because of legacy browser problem with HPR, when it's the only correct
approach IMO (well ALT is required, title is up to you.)
>(Interesting ethical issue: I have HPR on time-limited trial knowing I will
>never buy it. I'm not using it to trial the product - I am using it as a
>training course in accessibility. Hm!)
Surely you're trialling the product, with a view to buying it to
review the accessibililty of your pages?
Jim.