Alt-text Tags and D-links - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: Alt-text Tags and D-links

jake wrote
Quoted text here. Click to load it

You said "suggest a substitute". there it is, just up there ^. Ok then:

Which part of:

Quoted text here. Click to load it

did you fail to understand? CSS readily and correctly replaces 1 pixel gifs.

Quoted text here. Click to load it

No, it does not work that way. *You* have said 1 pixel gifs are good. *I*
have said they are bad. I don't have to provide an example where 1 pixel
gifs are bad (although I could, look at just about any site out there). It
is up to you to provide an example where you think a 1 pixels gif is good.

Please now do so, with an emphasis on why it aids accessibility.

I will then replace it with suitable, and more appropriate, CSS.

Cheers, in wait mode...

Re: Alt-text Tags and D-links

Quoted text here. Click to load it

You seem very defensive; I do hope I haven't touched a raw nerve.
Quoted text here. Click to load it
Well, let's go through the process then as you seem to need some help to
get started.

A page contains a list of events to be held this year (by some kind of
local society -- say, a local history society).
The events are in date order.
I want to have all the events for that year on the page (i.e. I do not
want to delete events now over).
When an assistive technology (AT) user accesses the page, I want them to
hear "Skip to the next active event" -- which is a link to the next
coming event. Logical, I guess.
But I want to keep the link invisible to graphics-active UAs.

At the top of the page I have:
<a href="#nextone" title="Skip to the next active event">
<img src="ONEPIX.GIF" alt="Skip to the next active event"
                                  height="1" width="1"></a>

When the AT user accesses the page they hear "Skip to the next active
event" in a 'links' voice. Pressing the appropriate key(s), the AT UA
then starts reading from '#nextone'.

Over to you.

BTW Don't bother with the CSS hack of positioning a link in hyperspace;
one hack is the same as another. But I'm sure you've got a better idea
...... ;-)


Re: Alt-text Tags and D-links

Quoted text here. Click to load it

<a class="speech-only" ... ></a>

@media screen {
  a.speech-only { display: none; }

Re: Alt-text Tags and D-links

Quoted text here. Click to load it

Contrary to popular opinion (especially by those that have never tried
it), this approach doesn't work.

Screen-readers and talking browsers will say ............. absolutely

(And it's one good reason why the FIR technique doesn't work in

Read more for full details: /


Re: Alt-text Tags and D-links

jake wrote:
Quoted text here. Click to load it

Which is precisely why everyone must use it. How else are we to encourage
proper implementation of CSS media selectors in user agents?

Toby A Inkster BSc (Hons) ARCS
Contact Me -

Re: Alt-text Tags and D-links

Quoted text here. Click to load it
Let me see if I understand you correctly.

You're advocating using something known not to work? Hmmmm. Doesn't
sound a very practical approach ;-)

(There is, of course, no media selector that currently describes a
screen-reader or talking browser adequately as these UAs are bi-modal.
i.e. synchronised sound and vision.)

You could pressure the w3c to adopt a new media type -- or a new CSS
option -- but let's not hold our breath on that one.

I guess we're stuck with having to deal with 'the real world' as we find



Re: Alt-text Tags and D-links

jake wrote:

Quoted text here. Click to load it

You betcha.

Depends on which is the greater of my two aims:

    - providing a skip link[1]; or
    - creating a site that encourages sane browsers.

If the latter then it's a very practical approach.

[1] As it happens skip links tend not to be very important on my sites --
they are usually not of the "skip navigation" type, but "skip *to*
navigation" which is generally less important as most screen readers have
a "skip to next link" feature built in.

Toby A Inkster BSc (Hons) ARCS
Contact Me -

Re: Alt-text Tags and D-links

Quoted text here. Click to load it

I have tried it, and it worked. That's a _specific_ reference to
screen media, not just the default for the page. Now I admit I'm not
familiar with screen readers (these tests were 5 years ago), but my
understanding was that for "the bi-modal problem", you could avoid
much of the trouble by stating an explicit media mode.

And what's wrong with this version:

@media screen {
  a.speech-only { display: none; }

@media aural {
  a.speech-only { display: inline ! important; }

Surely any screen reader that can't cascade that correctly is having a
really bad day ?

Re: Alt-text Tags and D-links

Quoted text here. Click to load it

The idea (most simply stated) is "annotate the incomprehensible and
make it accessible". This is a good idea, and I think most of us would
support it.

However their "d link" approach is bogus. Rather than marking up the
item that is affected, they link to a wholly separate resource. There
are a lot of things wrong with this:

Why it's a bad idea:

 - It's very far from obvious. What's this "d" floating around all
over the page?  Why should I want to click on that?

- It's itself an accessibility issue (and I think this is the most
serious problem) let's suppose I can't resolve the image because my
elderly vision is suffering, but I'd like to read a description of it.
How am I expected to find or recognise a single character as a link

- It's unusual. "d links" are _not_ common. As their only possible
usability depends on them having good branding and immediate
recognition, then that's serious.

 - It's patronising. Why not go the whole hog and label it
"Cripples click here (or get your carer to do it for you)"

 - And the killer: "Find out what the little "d" means"
This is effectively a user manual. We had those ten years ago, back
when computers were hard to use and scary. Nowadays anyone can use
computers for two things (and largely, that's all they do use them
for) browsing the web and playing games. You'll note that neither of
these rely on following a manual or instruction and that's _why_
they're successful. If you need to _explain_ it, you've failed as a
usability designer. If you need to explain a "usability" feature, then
that's ludicrous.

Why it's a poor implementation:

 - So what happens when you navigate a "d link" ?  You lose the page
context (this _would_ be a good use for a pop-up) and the annotation
replaces the entity it's describing. Think about that objectively for
a moment ?

 - There's nothing formal linking the resource to its annotation.

 - As far as machine-processable metadata goes, this is requiring the
page author to do a lot of work in setting up this annotation system,
then hiding the results from anything resembling a web crawler. Dumb.

What would have been better:

- Simple thing - Take that annotation, and display it on the page,
right alongside the thing it's describing. Why should the disabled get
all the fun?

 - Show the annotation on the page. Use CSS / JavaScript to hide it in
those circumstances when it's excessive and when the current browser
platform/config lets you do so (this isn't rocket science).

Quoted text here. Click to load it

It's not a bad site accessibility wise. Specifically it's a _simple_
site, and that's always a free-lunch for accessibility. Why worry
about the best way for a multi-column layout when you can simply avoid
it altogether?

We know this oh, we've seen _much_ worse !

But it's a site that has a target audience where accessibility, and
general web-naivety, are major issues. They're also "in the business"
of accessibility. As such, we expect _better_. They accept this
themselves else why bother with the Bobby eye-candy ?

The accessibility issues are largely minor things but equally they'd
have been minor things to correct. Why bother setting an alt and even
the (rarely-used) longdesc attribute on images, yet ignoring the title
attribute ?  I use Firefox as a browser I don't see these alt texts,
when I could so easily have been given them.  Kudos though for
realising that longdesc is a URI, not human-readable text.

How about a few titles elsewhere too?  Links should be titled it's
cheap to do, it's demonstrably useful to a whole lot of user
interaction models. It's usual that the text content of an <a> element
is equivalent to the title, but it's not always so. Placing something
into a title attribute is a direct indication that it's meaningful as
such, even if it's a mere duplication of the element's text content.
Maybe to you and I it's "obvious", but there are lots of assistive
technologies where it's anything but, and this strong hint is helpful
to them.

Lists could benefit from title too. Some of the lists, particularly
the footer menu bar should be marked-up as either <menu> or <ul>, yet
they're constructed from a simple <br> and list of (untitled) <a>'s .
There is no distinction being made here between "any old link" on the
page, and what is a fairly major navigation tool. Again, this is a
trivial issue, but it's still a _real_ issue, and it's an issue where
the fix is itself trivial.

Worst of all, the links on the home page _do_ have titles. Except that
instead of putting them in a sensible place, they're stuck underneath
some JavaScript roll-over code. Then they appear in the centre of the
page, well away from the mouse location and the actual link!  This
isn't just a disability accessibility issue, it's piss-poor design all

How about using <address> for that telephone contact number?  For
vision-restricted users that's just about the most useful part of the
page, yet there's no way to find or highlight it easily or
automatically?  Yes, this is me doing the SemWeb blue-sky pitch again,
but with trivial CSS in a user stylesheet _right_now_ I can make those
contact details light up for the user, for just the effort of adding
that element.

What's with the "Skip past menu items" link?  This jumps over the menu
footer, which is about three lines of text. It is pointless as a
navigation feature and simply adds excess crud. Perhaps there's a page
where it does have a function (in the right context, it's a good idea)
but using it in the pointless case like this also devalues it from
when it could have added something.

Accessibility isn't rocket science. I've seen almost no feature where
boosting accessibility was at all complicated almost every
improvement depended on _simplifying_ something, not adding bells and

They also have a number of eye-candy logos on the page the
ubiquitous "Valid HTML" button appears. Except that this page is not
only invalid mark-up, but it's not even HTML. They have legacy
bit-rot. Once this sets in, standards compliance falls apart and
pretty soon so does accessibility.

Re: Alt-text Tags and D-links

Quoted text here. Click to load it

Because it's pretty much a 'de facto' standard in the 'accessibility
business'. On encountering a 'd' (in a links voice) immediately after an
image, the AT user knows that there is an extended description
Quoted text here. Click to load it

If you're trying to find it visually, you won't (unless you're using a
magnifier program). If you're using an Assistive Technology (AT) UA then
you're going to hear it (or sense it).
Quoted text here. Click to load it

So the RNIB and other organisations for the vison-impaired have got it
all wrong?
Quoted text here. Click to load it
No more than a 'skip to main content' link at the start of a page is

Quoted text here. Click to load it

Like I say, if you're an AT user, you know what it means.

Quoted text here. Click to load it
See above.

Your 'd-link' page contains the link (for example) 'return to main page'
.... which is a link to where you were diverted on the calling page.
i.e. You go back to where you left off.
Quoted text here. Click to load it

Even those with 20-20 vision can 'click'(?). Don't just think of AT
users as 'vision impaired' ... there's a lot more reasons to use AT.
Quoted text here. Click to load it

Yes --  agree 100%.

Anyway, Andy, you're now raising a lot of isssues about that site which
I really need to go away and have a closer look at. I hope we can
discuss these later?
Quoted text here. Click to load it

You've raised a number of interesting points. We must talk later.



Re: Alt-text Tags and D-links

[snip previously discussed stuff]

Quoted text here. Click to load it
I don't really have a problem with this as the menu items seem pretty
much self-explanatory. The problem would be using Javascript to display
the additional information if it was useful.

Quoted text here. Click to load it

I'm not sure is this really is a problem. If I wanted their telephone
number I'd 'click' on "CONTACT". The telephone number is then the 2nd
item available on entering the page -- so fairly accessible?
Quoted text here. Click to load it

Yes. A waste of time.

What there *should* be is a 'skip to navigation' at the start of each
page. That way the menu would be available in about 2 key-strokes.
Quoted text here. Click to load it

Yes, it takes a lot of hard work to make a site truly inaccessible ...
but that doesn't stop people trying ;-)

Quoted text here. Click to load it

What do you make of: ??



Re: Alt-text Tags and D-links

Quoted text here. Click to load it

Not too good, the first things I noticed were:

A skip navigation link on page with no navigation.

summary="Layout" on a table that isn't being used for layout.
(Though it does have a lot of empty cells. The two cells containing
Subject and Last Modified should be <th> not <td> and if the table was
reduced to just those two columns it would obviously be a data table.)

Centered text is difficult to read.

Links that are black text with no underlines.

Text sizing done in pt so it can't be resized in Win IE.

Lots of JavaScript that doesn't seem to do anything and lots of
commented out form elements. Is this a work in progress or a live

Invalid XHTML.


"My theories appal you, my heresies outrage you,
 I never answer letters and you don't like my tie."  - The Doctor

Site Timeline