Good day,
When making a form in Dreamweaver it puts in id=same as name in to
every form item. When I take out all the id attributes the form still
works. Why are the id attributes being put in by DW and, more
importantly, is there an accessibility issue if I take them out?
i.e. -
Those IDs can be used as hooks to allow CSS and JavaScript to interact
with your individual form elements.
---
Dale Cruse
617.640.0856
http://www.DaleJCruse.com
On Wed, Aug 19, 2009 at 11:37 AM, Erickson, Kevin (DOE)
kevin.erick...@doe.virginia.gov wrote:
Good day,
When making a form in
On 19 Aug 2009, at 16:37, Erickson, Kevin (DOE) wrote:
When making a form in Dreamweaver it puts in id=same as name in to
every form item. When I take out all the id attributes the form
still works. Why are the id attributes being put in by DW and, more
importantly, is there an
I think the ID's are required for the 'for' attribute to work for labels,
which enables the their clickability. When these labels are clicked on they
focus on the element whose ID is in the for attribute.
label for=CommentsEnter you comments:/label
Plus having ID's associated allows for more
Correct the ID's are required for the for attribute of the LABEL tag to
work; but each ID must be unique.
Best Regards,
Nate Hanna
On Wed, Aug 19, 2009 at 11:54 AM, James O'Neill freexe...@gmail.com wrote:
I think the ID's are required for the 'for' attribute to work for labels,
which
On a slightly related topic, I have wrapped inputs inside of labels
for browser compatibility for the label clickability/focus issue
(based on some research some time ago), but have just read for the
first time recently, that this is not a good idea. Any thoughts?
On Wed, Aug 19, 2009 at 11:54
Hmmm... I do not really remember.
I have used both together and separately at different times.
By enclosing a form control with a label you will have a little more control
over relative styling since you could something like this:
label:hover input {outline:solidl}
or have more precise
@webstandardsgroup.org
Subject: Re: [WSG] Accessible Forms
On a slightly related topic, I have wrapped inputs inside of labels for
browser compatibility for the label clickability/focus issue (based on
some research some time ago), but have just read for the first time
recently
On 19 Aug 2009, at 19:35, Tom Livingston wrote:
On a slightly related topic, I have wrapped inputs inside of labels
for browser compatibility for the label clickability/focus issue
(based on some research some time ago), but have just read for the
first time recently, that this is not a good
Subject: Re: [WSG] Accessible Forms
On a slightly related topic, I have wrapped inputs inside of labels for
browser compatibility for the label clickability/focus issue (based on
some research some time ago), but have just read for the first time
recently, that this is not a good idea. Any thoughts
The reason I use this was because I found an easy way to style forms
that included the broader compatibility for the clickability of labels
for focus with the flexibility of layout with the inclusion of a span
like:
label for=name
spanFirst Name/span
input type=text /
/label
I use this a lot for
For clarity, I submit this edit:
label for=name
spanFirst Name/span
input type=text id=name /
/label
The for attribute matches the input ID. Always.
On Wed, Aug 19, 2009 at 3:09 PM, Tom Livingstontom...@gmail.com wrote:
The reason I use this was because I found an easy way to style forms
-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of Tom Livingston
Sent: 19 August 2009 20:10
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Accessible Forms
The reason I use this was because I found an easy way to style forms
On 19/08/2009 20:04, David Dorward wrote:
On 19 Aug 2009, at 19:35, Tom Livingston wrote:
On a slightly related topic, I have wrapped inputs inside of labels
for browser compatibility for the label clickability/focus issue
(based on some research some time ago), but have just read for the
Wow! So what is the best practice???
-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]
On Behalf Of Steve Green
Sent: Wednesday, August 19, 2009 3:59 PM
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] Accessible Forms
-Original Message
...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]
On Behalf Of Steve Green
Sent: Wednesday, August 19, 2009 3:59 PM
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] Accessible Forms
-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]
On Behalf Of Tom
@webstandardsgroup.org
Subject: RE: [WSG] Accessible Forms
--
Tom Livingston | Senior Interactive Developer | Media Logic |
ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
@webstandardsgroup.org
Subject: Re: [WSG] Accessible Forms
On 19/08/2009 20:04, David Dorward wrote:
On 19 Aug 2009, at 19:35, Tom Livingston wrote:
On a slightly related topic, I have wrapped inputs inside of labels
for browser compatibility for the label clickability/focus issue
(based on some research some
FYI- I did replace align=right align=center with CSS styling.
-Original Message-
From: Erickson, Kevin (DOE)
Sent: Wednesday, August 19, 2009 4:33 PM
To: 'wsg@webstandardsgroup.org'
Subject: RE: [WSG] Accessible Forms
I have two simple forms. Which is better?:
http
FYI- I did replace align=right align=center with CSS styling.
-Original Message-
From: Erickson, Kevin (DOE)
Sent: Wednesday, August 19, 2009 4:33 PM
To: 'wsg@webstandardsgroup.org'
Subject: RE: [WSG] Accessible Forms
I have two simple forms. Which is better?:
http
Here are some best practices examples. The encapsulation method has
some side effects that any content in text form controls becomes part
of the label, which can be confusing to speech users.
http://html.cita.illinois.edu/nav/form
Jon
On Wed, Aug 19, 2009 at 2:04 PM, David
-
From: Erickson, Kevin (DOE)
Sent: Wednesday, August 19, 2009 4:33 PM
To: 'wsg@webstandardsgroup.org'
Subject: RE: [WSG] Accessible Forms
I have two simple forms. Which is better?:
http://www.doedev.vi.virginia.gov/z_testing_area/kevin/form_mail_vi/form
_mailer4.shtml
Code:
form
Hi Folks,
In case you are interested...
Roger Hudson has written a detailed article called Accessible
Forms using WCAG 2.0. The article provides practical advice about the
preparation of accessible HTML forms.
http://www.usability.com.au/resources/wcag2/
More importantly, it compares the WCAG
Hi,
Doesn't look like valid code to me.
Stuart
On Thu, April 12, 2007 2:07 pm, Nick Fitzsimons wrote:
On 12 Apr 2007, at 13:34:06, Patrick Lauke wrote:
I'm not making assumptions. I'm saying that, for sighted users,
having a text input box with no visible label and a button that
says
On 14 Apr 2007, at 07:25:29, Stuart Foulstone wrote:
Hi,
Doesn't look like valid code to me.
Stuart
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/
TR/html4/strict.dtdhtml
head
titleblah/title
/head
body
form action=
div
label for=searchBox
input type=text
Mmm,
not really the kind of label tags we were discussing.
Stuart
On Sat, April 14, 2007 9:08 am, Matthew Pennell wrote:
PS: Link for you: http://alistapart.com/articles/alphabet
;)
***
List Guidelines:
Bojana Lalic wrote:
Hi all
Accverify fails my code because my input element does not contain the
alt attribute or label.
I don't want any text displayed before or after the query text input
element. Should I wrap a label around the input element and then hide it
using css? How do I get
Nick Fitzsimons
Surely
label for=searchBox
input type=text id=searchBox name=q
button type=submitSearch/button
/label
would therefore keep everybody happy?
Depends on AT support (whether or not a screenreader would actually be able to
make sense of this construct and expose
Hi,
The labels are there for accessibility reasons, if you don't want to
design for accessibility, don't pretend to.
Stuart
On Thu, April 12, 2007 1:55 am, Bojana Lalic wrote:
Hi all
Accverify fails my code because my input element does not contain the
alt attribute or label.
I don't
The labels are also clickable to focus on their respective fields so I
wouldn't say they are purely accessibility oriented in nature.
Stuart Foulstone wrote:
Hi,
The labels are there for accessibility reasons, if you don't want to
design for accessibility, don't pretend to.
Stuart
On Thu,
Hi,
Since the ability to click on the label (or field) to put focus on the
field is an accessibility feature of forms, I don't really understand your
point.
Stuart
On Thu, April 12, 2007 9:40 am, Jixor - Stephen I wrote:
The labels are also clickable to focus on their respective fields so I
I would refer to that as usability.
Stuart Foulstone wrote:
Hi,
Since the ability to click on the label (or field) to put focus on the
field is an accessibility feature of forms, I don't really understand your
point.
Stuart
On Thu, April 12, 2007 9:40 am, Jixor - Stephen I wrote:
The
Stuart Foulstone
If you're only concerned about providing form accessibility for
screenreaders, and no other disability, you could use the
method below or
a transparent.gif with appropriate alt-text would work too.
Not necessarily just for screenreader accessibility. If the input itself is
Sorry, I thought we were discussing labels for form input boxes (not just
one-box input search forms).
However, generally speaking, making assumptions about accessibility based
on the visual positioning of elements in a logical common place used by
most other sites is not a good idea.
Better to
On 12 Apr 2007, at 13:34:06, Patrick Lauke wrote:
I'm not making assumptions. I'm saying that, for sighted users,
having a text input box with no visible label and a button that
says Search immediately next to it is labelling enough.
Surely
label for=searchBox
input type=text
Nick Fitzsimons
Surely
label for=searchBox
input type=text id=searchBox name=q
button type=submitSearch/button
/label
would therefore keep everybody happy?
Depends on AT support (whether or not a screenreader would actually be able to
make sense of this construct and expose
Hi all
Accverify fails my code because my input element does not contain the
alt attribute or label.
I don't want any text displayed before or after the query text input
element. Should I wrap a label around the input element and then hide it
using css? How do I get around this
Bojana Lalic wrote:
I don’t want any text displayed before or after the query text input
element. Should I wrap a label around the input element and then hide it
using css? How do I get around this accessibility issue?
Me personally, I setup my form normally using label/input, then apply
38 matches
Mail list logo
