E-mail List Archives
Re: Buttons and label tags
From: Jukka K. Korpela
Date: Feb 10, 2005 5:16AM
- Next message: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;: "Re: Buttons and label tags"
- Previous message: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;: "Re: Buttons and label tags"
- Next message in Thread: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;: "Re: Buttons and label tags"
- Previous message in Thread: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;: "Re: Buttons and label tags"
- View all messages in this Thread
On Thu, 10 Feb 2005, kieranmobrien wrote:
> Personally I think the button works quite well, apart from the obvious
> limitations.
There are many more limitations than what people might see as obvious.
I could list down about a dozen different limitations.
> I don't think a link on the name of the store would be
> intuitive enough.
It might be unintuitive that the link points to a map. But such things can
be briefly explained before the list of links. Besides, there's the option
of putting an icon similar to a button and suggesting "this points to a
map" after the link, e.g.
address here
(You could also use alt="(map)" for example, but I don't think people
using speech browsers would like to hear that for each link.
Rather they would like to hear the information before the list.)
> It's hard to say without seeing an example.
> Unfortunately it is a secure site so I can't give out a URL.
Sorry, you lost me there. How is it hard to say to _you_, then?
Besides, "secure" normally means SSL encryption (https) in contexts like
this, and it does not mean restricted access. If it's really for limited
audience, then I guess there's no other way to get specific help with it
than to prepare a copy thereof that has the confidential data removed and
make the copy available to all.
> My issue with this is with people using speech browsers. If they tab
> to the first link i.e. the map button and then tab again to the next
> map button, it is quite awkward for them to know which relates to
> which.
That's one reason why making the addresses links is better. But although
the page might conceivable be used in "links reading" mode, I would expect
that people would normally listen to the content sequentially, so they
would hear the map link right after the address. But this still
unnecessarily deviates from the common link concept.
> Sorry I should have been clear by my use of the word button. It is not
> a form element but rather an image (shaped as a button) with a href,
> hence it has alt text and would therefore appear in a list of links.
It really changes things. In particular, is not meant for use with
links. And if you have essentially map several times, it
the list of all links on a page becomes probably useless, if the list
should really contain the addresses. Besides, it would violate the
specific requirement that no two links shall have the same link text on a
page if they point to different resources.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
- Next message: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;: "Re: Buttons and label tags"
- Previous message: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;: "Re: Buttons and label tags"
- Next message in Thread: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;: "Re: Buttons and label tags"
- Previous message in Thread: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;: "Re: Buttons and label tags"
- View all messages in this Thread