E-mail List Archives
Thread: Submitting forms via javascript: Button vs. link vs. other?
Number of posts in this thread: 18 (In chronological order)
From: D A
Date: Thu, Dec 03 2009 3:54PM
Subject: Submitting forms via javascript: Button vs. link vs. other?
No previous message | Next message →
Assuming Javascript is enabled (I know that, itself, can be an
accessibility issue) what are the pros/cons of using various elements
to act as the trigger for submission?
We could use a button, anchor tag, or span.
What I've come up with:
button: pro - it's a form. A button makes sense in the traditional
sense; con - they can be a pain to style
anchor tag : pro - being a link, it makes sense as a 'clickable'
object; Con - submitting a form isn't the same as clicking a link.
Perhaps this is in appropriate and potentially an issue with indexing
spiders and the like.
span (or other neutral element): pro - easy to style and doesn't have
the cons of the above; con - is there one?
Thoughts? Am I overthinking this?
-DA
From: Stephan Wehner
Date: Thu, Dec 03 2009 4:15PM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
On Thu, Dec 3, 2009 at 2:54 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:
> Assuming Javascript is enabled (I know that, itself, can be an
> accessibility issue) what are the pros/cons of using various elements
> to act as the trigger for submission?
>
> We could use a button, anchor tag, or span.
>
> What I've come up with:
>
> button: pro - it's a form. A button makes sense in the traditional
> sense; con - they can be a pain to style
>
> anchor tag : pro - being a link, it makes sense as a 'clickable'
> object; Con - submitting a form isn't the same as clicking a link.
> Perhaps this is in appropriate and potentially an issue with indexing
> spiders and the like.
>
> span (or other neutral element): pro - easy to style and doesn't have
> the cons of the above; con - is there one?
Are you looking for alternatives to the usual (and fourth option)
<input type="submit" ...>, which is different from <button
type="submit" ...> ... </button>, in order to be able apply more
styling to the button?
Stephan
> Thoughts? Am I overthinking this?
>
> -DA
>
From: Jared Smith
Date: Thu, Dec 03 2009 4:21PM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
On Thu, Dec 3, 2009 at 3:54 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:
> Assuming Javascript is enabled (I know that, itself, can be an
> accessibility issue) what are the pros/cons of using various elements
> to act as the trigger for submission?
I think you've covered most of the issues. Naturally buttons are
capable of submitting without javascript, so that's an important point
to consider.
> Perhaps this is in appropriate and potentially an issue with indexing
> spiders and the like.
Yes, you'll have spiders following your link all the time (unless you
add nofollow... maybe), but they don't typically have javascript
enabled, so it won't really submit your form anyway.
> span (or other neutral element): pro - easy to style and doesn't have
> the cons of the above; con - is there one?
Spans cannot receive keyboard focus by default, so they are not
suitable unless you assign them tabindex="0" to make them tabable.
My approach, assuming I can't style the button how I want to, would be
to use a button in the standard HTML, then use scripting to replace
the button with my styled link, but assign it an ARIA role of button
so that screen readers treat it and identify the link as a button.
They won't know the difference between the link and a button. This
approach has all of the pros you list and none of the cons. It also
uses progressive enhancement so it works without scripting.
Jared Smith
WebAIM
From: Moore,Michael (DARS)
Date: Fri, Dec 04 2009 8:00AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
We have found usability problems caused for screen reader users when links are styled to look like buttons. The basic scenario goes like this.
JAWS user calls the help desk for assistance with a web application.
Help desk technician walks the person through the process in the application.
Everything goes fine until the technician tell the JAWS user, "Now click on the Process Transaction Button"
JAWS user whacks the B key, or attempts to bring up a list of buttons and JAWS says "no buttons found on page"
JAWS user tells help desk technician there is no Process Transaction button on the page.
Help desk technician says sure there is, it's right next to the Cancel button ...
Buttons really need to be buttons.
Mike Moore
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
Sent: Thursday, December 03, 2009 5:19 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Submitting forms via javascript: Button vs. link vs. other?
On Thu, Dec 3, 2009 at 3:54 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:
> Assuming Javascript is enabled (I know that, itself, can be an
> accessibility issue) what are the pros/cons of using various elements
> to act as the trigger for submission?
I think you've covered most of the issues. Naturally buttons are
capable of submitting without javascript, so that's an important point
to consider.
> Perhaps this is in appropriate and potentially an issue with indexing
> spiders and the like.
Yes, you'll have spiders following your link all the time (unless you
add nofollow... maybe), but they don't typically have javascript
enabled, so it won't really submit your form anyway.
> span (or other neutral element): pro - easy to style and doesn't have
> the cons of the above; con - is there one?
Spans cannot receive keyboard focus by default, so they are not
suitable unless you assign them tabindex="0" to make them tabable.
My approach, assuming I can't style the button how I want to, would be
to use a button in the standard HTML, then use scripting to replace
the button with my styled link, but assign it an ARIA role of button
so that screen readers treat it and identify the link as a button.
They won't know the difference between the link and a button. This
approach has all of the pros you list and none of the cons. It also
uses progressive enhancement so it works without scripting.
Jared Smith
WebAIM
From: Don Mauck
Date: Fri, Dec 04 2009 8:06AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
Yes, as a JAWS and Window-eyes user I have seen this a lot on pages where the button is really more like a link even though the sighted user sees it as a button. In reality its a javascript that has the graphical look of a button but triggers much like a link so the AT package never sees that it really is meant to be a button.
Regards,
Don
Oracle
Don Mauck | Accessibility Evangelist
Oracle Corporate Architecture Group
7700 Technology Way
Denver CO 80237
Phone (303) 334-4184
Email = EMAIL ADDRESS REMOVED =
Green Oracle
Oracle is committed to developing practices and products that help protect the environment
-----Original Message-----
From: Moore,Michael (DARS) [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, December 04, 2009 8:00 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Submitting forms via javascript: Button vs. link vs. other?
We have found usability problems caused for screen reader users when links are styled to look like buttons. The basic scenario goes like this.
JAWS user calls the help desk for assistance with a web application.
Help desk technician walks the person through the process in the application.
Everything goes fine until the technician tell the JAWS user, "Now click on the Process Transaction Button"
JAWS user whacks the B key, or attempts to bring up a list of buttons and JAWS says "no buttons found on page"
JAWS user tells help desk technician there is no Process Transaction button on the page.
Help desk technician says sure there is, it's right next to the Cancel button ...
Buttons really need to be buttons.
Mike Moore
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
Sent: Thursday, December 03, 2009 5:19 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Submitting forms via javascript: Button vs. link vs. other?
On Thu, Dec 3, 2009 at 3:54 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:
> Assuming Javascript is enabled (I know that, itself, can be an
> accessibility issue) what are the pros/cons of using various elements
> to act as the trigger for submission?
I think you've covered most of the issues. Naturally buttons are capable of submitting without javascript, so that's an important point to consider.
> Perhaps this is in appropriate and potentially an issue with indexing
> spiders and the like.
Yes, you'll have spiders following your link all the time (unless you add nofollow... maybe), but they don't typically have javascript enabled, so it won't really submit your form anyway.
> span (or other neutral element): pro - easy to style and doesn't have
> the cons of the above; con - is there one?
Spans cannot receive keyboard focus by default, so they are not suitable unless you assign them tabindex="0" to make them tabable.
My approach, assuming I can't style the button how I want to, would be to use a button in the standard HTML, then use scripting to replace the button with my styled link, but assign it an ARIA role of button so that screen readers treat it and identify the link as a button.
They won't know the difference between the link and a button. This approach has all of the pros you list and none of the cons. It also uses progressive enhancement so it works without scripting.
Jared Smith
WebAIM
From: ben morrison
Date: Fri, Dec 04 2009 8:12AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
On Fri, Dec 4, 2009 at 2:59 PM, Moore,Michael (DARS)
< = EMAIL ADDRESS REMOVED = > wrote:
> We have found usability problems caused for screen reader users when links are styled to look like buttons. The basic scenario goes like this.
...
>
> Buttons really need to be buttons.
Exactly, why reinvent what actually works for everyone - what with the
current browser support for CSS button styling you should be able to
achieve almost any design required,
you will loose the :hover state in IE - but its a small price - you
could always add some JS to insert a simple hover class on rollover if
client requests...
ben
--
Ben Morrison
From: Geof Collis
Date: Fri, Dec 04 2009 8:39AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
Hi Ben
What do you mean "lose the hover state in I?E" ? I use cs hover on my
main links with no problem. Or are we talking 2 differnet issues.
cheers
Geof
At 10:09 AM 12/4/2009, you wrote:
>On Fri, Dec 4, 2009 at 2:59 PM, Moore,Michael (DARS)
>< = EMAIL ADDRESS REMOVED = > wrote:
> > We have found usability problems caused for screen reader users
> when links are styled to look like buttons. The basic scenario goes like this.
>...
> >
> > Buttons really need to be buttons.
>
>Exactly, why reinvent what actually works for everyone - what with the
>current browser support for CSS button styling you should be able to
>achieve almost any design required,
>you will loose the :hover state in IE - but its a small price - you
>could always add some JS to insert a simple hover class on rollover if
>client requests...
>
>ben
>--
>Ben Morrison
>
From: ben morrison
Date: Fri, Dec 04 2009 8:51AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
Hi,
IE 6 (and below) will only apply :hover states to ANCHOR elements :)
http://kimblim.dk/css-tests/selectors/
ben
On Fri, Dec 4, 2009 at 3:37 PM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Ben
>
> What do you mean "lose the hover state in I?E" ? I use cs hover on my
> main links with no problem. Or are we talking 2 differnet issues.
>
> cheers
>
> Geof
>
>
>
> At 10:09 AM 12/4/2009, you wrote:
>>On Fri, Dec 4, 2009 at 2:59 PM, Moore,Michael (DARS)
>>< = EMAIL ADDRESS REMOVED = > wrote:
>> > We have found usability problems caused for screen reader users
>> when links are styled to look like buttons. The basic scenario goes like this.
>>...
>> >
>> > Buttons really need to be buttons.
>>
>>Exactly, why reinvent what actually works for everyone - what with the
>>current browser support for CSS button styling you should be able to
>>achieve almost any design required,
>>you will loose the :hover state in IE - but its a small price - you
>>could always add some JS to insert a simple hover class on rollover if
>>client requests...
>>
>>ben
>>--
>>Ben Morrison
>>
From: Geof Collis
Date: Fri, Dec 04 2009 9:00AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
Still dont get it, I thought the discussion was creating a link to
look like a button using css.
cheers
Geof
At 10:44 AM 12/4/2009, you wrote:
>Hi,
>
>IE 6 (and below) will only apply :hover states to ANCHOR elements :)
>
>http://kimblim.dk/css-tests/selectors/
>
>ben
>
>On Fri, Dec 4, 2009 at 3:37 PM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi Ben
> >
> > What do you mean "lose the hover state in I?E" ? I use cs hover on my
> > main links with no problem. Or are we talking 2 differnet issues.
> >
> > cheers
> >
> > Geof
> >
> >
> >
> > At 10:09 AM 12/4/2009, you wrote:
> >>On Fri, Dec 4, 2009 at 2:59 PM, Moore,Michael (DARS)
> >>< = EMAIL ADDRESS REMOVED = > wrote:
> >> > We have found usability problems caused for screen reader users
> >> when links are styled to look like buttons. The basic scenario
> goes like this.
> >>...
> >> >
> >> > Buttons really need to be buttons.
> >>
> >>Exactly, why reinvent what actually works for everyone - what with the
> >>current browser support for CSS button styling you should be able to
> >>achieve almost any design required,
> >>you will loose the :hover state in IE - but its a small price - you
> >>could always add some JS to insert a simple hover class on rollover if
> >>client requests...
> >>
> >>ben
> >>--
> >>Ben Morrison
> >>
From: ben morrison
Date: Fri, Dec 04 2009 9:03AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
The discussion was that you should keep a button/submit as its a form
and not use a link....
"what with the current browser support for CSS BUTTON styling you
should be able to
achieve almost any design required, you will loose the :hover state in IE"
ben
On Fri, Dec 4, 2009 at 4:00 PM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
> Still dont get it, I thought the discussion was creating a link to
> look like a button using css.
>
> cheers
>
> Geof
>
> At 10:44 AM 12/4/2009, you wrote:
>>Hi,
>>
>>IE 6 (and below) will only apply :hover states to ANCHOR elements :)
>>
>>http://kimblim.dk/css-tests/selectors/
>>
>>ben
>>
>>On Fri, Dec 4, 2009 at 3:37 PM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
>> > Hi Ben
>> >
>> > What do you mean "lose the hover state in I?E" ? I use cs hover on my
>> > main links with no problem. Or are we talking 2 differnet issues.
>> >
>> > cheers
>> >
>> > Geof
>> >
>> >
>> >
>> > At 10:09 AM 12/4/2009, you wrote:
>> >>On Fri, Dec 4, 2009 at 2:59 PM, Moore,Michael (DARS)
>> >>< = EMAIL ADDRESS REMOVED = > wrote:
>> >> > We have found usability problems caused for screen reader users
>> >> when links are styled to look like buttons. The basic scenario
>> goes like this.
>> >>...
>> >> >
>> >> > Buttons really need to be buttons.
>> >>
>> >>Exactly, why reinvent what actually works for everyone - what with the
>> >>current browser support for CSS button styling you should be able to
>> >>achieve almost any design required,
>> >>you will loose the :hover state in IE - but its a small price - you
>> >>could always add some JS to insert a simple hover class on rollover if
>> >>client requests...
>> >>
>> >>ben
>> >>--
>> >>Ben Morrison
>> >>
From: Geof Collis
Date: Fri, Dec 04 2009 9:12AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
Ok, now I get it. Dont know why someone would
want to substitute a css styled link for a button
anyway. I find elements like that on a page
simply by hitting the f key, I find it very handy
when navigating past blocks of text etc.
cheers
Geof
At 11:03 AM 12/4/2009, you wrote:
>The discussion was that you should keep a
>button/submit as its a form and not use a
>link.... "what with the current browser support
>for CSS BUTTON styling you should be able to
>achieve almost any design required, you will
>loose the :hover state in IE" ben On Fri, Dec 4,
>2009 at 4:00 PM, Geof Collis
>< = EMAIL ADDRESS REMOVED = > wrote: > Still dont get
>it, I thought the discussion was creating a link
>to > look like a button using css. > >
>cheers > > Geof > > At 10:44 AM 12/4/2009, you
>wrote: >>Hi, >> >>IE 6 (and below) will only
>apply  :hover states to ANCHOR elements
>:) >> >>http://kimblim.dk/css-tests/selectors/ >>
> >>ben >> >>On Fri, Dec 4, 2009 at 3:37 PM,
>Geof Collis < = EMAIL ADDRESS REMOVED = > wrote: >> > Hi
>Ben >> > >> > What do you mean "lose the hover
>state in I?E" ? I use cs hover on my >> > main
>links with no problem. Or are we talking 2
>differnet issues. >> > >> > cheers >> > >> >
>Geof >> > >> > >> > >> > At 10:09 AM 12/4/2009,
>you wrote: >> >>On Fri, Dec 4, 2009 at 2:59 PM,
>Moore,Michael
>(DARS) >> >>< = EMAIL ADDRESS REMOVED = >
>wrote: >> >> > We have found usability problems
>caused for screen reader users >> >> when links
>are styled to look like buttons. The basic
>scenario >> goes like
>this. >> >>... >> >> > >> >> > Buttons really
>need to be buttons. >> >> >> >>Exactly, why
>reinvent what actually works for everyone - what
>with the >> >>current browser support for CSS
>button styling you should be able
>to >> >>achieve almost any design
>required, >> >>you will loose the :hover state
>in IE - but its a small price - you >> >>could
>always add some JS to insert a simple hover
>class on rollover if >> >>client
>requests... >> >> >> >>ben >> >>-- >> >>Ben
>Morrison >> >>
From: D A
Date: Fri, Dec 04 2009 9:30AM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
On Fri, Dec 4, 2009 at 9:09 AM, ben morrison < = EMAIL ADDRESS REMOVED = > wrote:
> Exactly, why reinvent what actually works for everyone - what with the
> current browser support for CSS button styling you should be able to
> achieve almost any design required,
We're going to a few issues with IE6, but that's nothing new. Besides,
that's not an excuse to break usability/accessibility. So I agree. I
think we're going to go forward making these actual form buttons and
see what we can do!
Thanks for all the feedback everyone!
-Darrel
From: Rowan @ Jetboy
Date: Fri, Dec 04 2009 12:24PM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
Definitely <input> or <button> elements. I'd suggest <input type="image"...
for a graphical submit button. I'm not aware of any accessibility issues
with this approach, apart from if the user has images switched off, but this
is something you're going to hit with any image based method, and <input
type="image"... does still work with no images. You could even use
traditional <input type="submit"... elements and use JavaScript to rewrite
them to <input type "image"... ones. Trying to style <input type="submit"...
elements cross-browser is a thankless task.
<snip>
Assuming Javascript is enabled (I know that, itself, can be an
accessibility issue) what are the pros/cons of using various elements
to act as the trigger for submission?
We could use a button, anchor tag, or span.
What I've come up with:
button: pro - it's a form. A button makes sense in the traditional
sense; con - they can be a pain to style
anchor tag : pro - being a link, it makes sense as a 'clickable'
object; Con - submitting a form isn't the same as clicking a link.
Perhaps this is in appropriate and potentially an issue with indexing
spiders and the like.
span (or other neutral element): pro - easy to style and doesn't have
the cons of the above; con - is there one?
Thoughts? Am I overthinking this?
-DA
From: Geof Collis
Date: Fri, Dec 04 2009 12:36PM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
What if someone wanted to zoom in or zoom out the graphical link?
cheers
Geof
At 02:12 PM 12/4/2009, you wrote:
>Definitely <input> or <button> elements. I'd suggest <input type="image"...
>for a graphical submit button. I'm not aware of any accessibility issues
>with this approach, apart from if the user has images switched off, but this
>is something you're going to hit with any image based method, and <input
>type="image"... does still work with no images. You could even use
>traditional <input type="submit"... elements and use JavaScript to rewrite
>them to <input type "image"... ones. Trying to style <input type="submit"...
>elements cross-browser is a thankless task.
>
><snip>
>
>Assuming Javascript is enabled (I know that, itself, can be an
>accessibility issue) what are the pros/cons of using various elements
>to act as the trigger for submission?
>
>We could use a button, anchor tag, or span.
>
>What I've come up with:
>
>button: pro - it's a form. A button makes sense in the traditional
>sense; con - they can be a pain to style
>
>anchor tag : pro - being a link, it makes sense as a 'clickable'
>object; Con - submitting a form isn't the same as clicking a link.
>Perhaps this is in appropriate and potentially an issue with indexing
>spiders and the like.
>
>span (or other neutral element): pro - easy to style and doesn't have
>the cons of the above; con - is there one?
>
>Thoughts? Am I overthinking this?
>
>-DA
>
>
From: Keith Parks
Date: Fri, Dec 04 2009 1:03PM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
On Dec 4, 2009, at 11:36 AM, Geof Collis wrote:
> What if someone wanted to zoom in or zoom out the graphical link?
>
Depends on how they are zooming.
One thing that helps if users are zooming the text size, you can
create your graphic oversize (say, 200% of what you consider "normal"
size) and then spec the display size of the image in EMs through css.
That way when the font size increases, the size of the image will
increase also.
(granted, Macs render images resized this way better than Windows,
though I don't know if Windows 7 has improved in this area.)
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
World Peace through Cascading Style Sheets.
From: Jukka K. Korpela
Date: Fri, Dec 04 2009 1:27PM
Subject: Re: Submitting forms via javascript: Button vs. link vs.other?
← Previous message | Next message →
Rowan @ Jetboy wrote:
> Definitely <input> or <button> elements.
Definitely what? Your method of replying is not accessible. It is not clear
at all what question you are responding to.
> I'd suggest <input
> type="image"... for a graphical submit button.
Oh my-
> I'm not aware of any
> accessibility issues with this approach, apart from if the user has
> images switched off,
I think we can stop here. The possibility of "images switched off" is of
course very real, but not at all the only issue here. Actually, if you are
suggesting an image submit button as an answer to an unspecified problem, I
think you now need a crash course on accessibility.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: Geof Collis
Date: Fri, Dec 04 2009 1:57PM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | Next message →
Wow! No wonder we run into so many problems, why not let the button
be what it is. Why so many convoluted answers to somethig that
doesn't need one.
At 03:03 PM 12/4/2009, you wrote:
>On Dec 4, 2009, at 11:36 AM, Geof Collis wrote:
>
> > What if someone wanted to zoom in or zoom out the graphical link?
> >
>
>Depends on how they are zooming.
>
>One thing that helps if users are zooming the text size, you can
>create your graphic oversize (say, 200% of what you consider "normal"
>size) and then spec the display size of the image in EMs through css.
>That way when the font size increases, the size of the image will
>increase also.
>
>(granted, Macs render images resized this way better than Windows,
>though I don't know if Windows 7 has improved in this area.)
>
>******************************
>Keith Parks
>Graphic Designer/Web Designer
>Student Affairs Communications Services
>San Diego State University
>San Diego, CA 92182-7444
>(619) 594-1046
>mailto: = EMAIL ADDRESS REMOVED =
>http://www.sa.sdsu.edu/communications
>
>http://kparks.deviantart.com/gallery
>----------------------------------------------------------
>
>World Peace through Cascading Style Sheets.
>
>
>
From: Keith Parks
Date: Fri, Dec 04 2009 2:09PM
Subject: Re: Submitting forms via javascript: Button vs. link vs. other?
← Previous message | No next message
On Dec 4, 2009, at 12:57 PM, Geof Collis wrote:
> Wow! No wonder we run into so many problems, why not let the button
> be what it is. Why so many convoluted answers to somethig that
> doesn't need one.
>
I'm not suggesting that someone *should* use a graphic in place of a
Submit button. I only offered the technique as a work-around to the
zooming issue.
Actually, where I think this method can work nicely is in those
instances where a graphic is used as a heading or subhead, when the
client or designer insists on matching a particular font or style.
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
Putting the "no" in "Innovation" since 1988.