E-mail List Archives
Thread: help with a form please
Number of posts in this thread: 19 (In chronological order)
From: Cheryl Amato
Date: Thu, Mar 15 2007 4:50PM
Subject: help with a form please
No previous message | Next message →
I have a form (not my design) that needs be made accessible. You will see by the code that there is a combination of radio buttons and input fields. I have included a bit of the code as that may be easier than any explanation I can give. I've never seen this kind of setup before and am unsure as to how it should be handled. I know that <label> must be added to the input fields especially since they are in different table rows. But what do I do with the radio buttons? They are "sharing" the same text label.
Any help would be greatly appreciated.
<table border="0">
<tr>
<td colspan="2"><b>Candidate:</b></td>
</tr>
<tr>
<td><input type="radio" name="ctrecipient" value="ct_acct">
Committee:</td>
<td> <INPUT size="25" name="iacct_name" ID="iacct_name"></td>
</tr>
<tr>
<td colspan="2">or</td>
</tr>
<tr>
<td><input type="radio" name="ctrecipient" value="ct_nm"> Candidate: </td>
<td><table border="0">
<tr>
<td>First Name: </td>
<td>Last Name: </td>
</tr>
<tr>
<td><INPUT size="25" name="icand_fname" ID="icand_fname"></td>
<td><INPUT size="25" name="icand_lname" ID="icand_lname"></td>
</tr>
</table>
</td>
</tr>
Cheryl Amato
Trusted Technologies
From: Travis Roth
Date: Thu, Mar 15 2007 6:50PM
Subject: Re: help with a form please
← Previous message | Next message →
Hi,
Since a label tag cannot be shared amongst input controls, an option would
be to create redundant labels and then use CSS to place them off-screen.
Currently screen readers support the use of the same ID attribute on
multiple controls referencing one label, but since technically an ID is to
be specific to an individual control this is an illegal practice. And you
never know when AT will stop supporting this.
From: Chris Price
Date: Thu, Mar 15 2007 7:10PM
Subject: Re: help with a form please
← Previous message | Next message →
Cheryl Amato wrote:
> I have a form (not my design) that needs be made accessible. You will see by the code that there is a combination of radio buttons and input fields. I have included a bit of the code as that may be easier than any explanation I can give. I've never seen this kind of setup before and am unsure as to how it should be handled. I know that <label> must be added to the input fields especially since they are in different table rows. But what do I do with the radio buttons? They are "sharing" the same text label.
>
>
How about this:
<table><caption>Candidate:</caption>
<tbody>
<tr>
<th scope="row"><input type="radio" name="ctrecipient"
id="ct_acct" value="ct_acct"> <label for="ct_acct">Committee</label></th>
<td><label for="iacct_name">Name:</label></td><td><input
size="25" name="iacct_name" id="iacct_name"></td>
</tr>
<tr><td>or</td></tr>
<tr>
<th scope="row" rowspan="2"><input type="radio"
name="ctrecipient" id="ct_nm" value="ct_nm"> <label
for="ct_nm">Candidate:</label></th>
<td><label for="icand_fname">First
Name:</label></td><td><input size="25" name="icand_fname"
id="icand_fname"></td>
</tr>
<tr>
<td><label for="icand_lname">Last
Name:</label></td><td><input size="25" name="icand_lname"
id="icand_lname"></td>
</tr>
</tbody>
</table>
I've used the input values for id's rather than the names. As far as I
can see, as long as all id's are unique and the label and input id's
match then it should be OK.
I've also tried to make sense of the rows and columns so that the table
is more than a placeholder.
I didn't think it made sense to have 2 tables either.
Kind Regards
--
Chris Price
Choctaw
= EMAIL ADDRESS REMOVED =
http://www.choctaw.co.uk
Tel. 01524 825 245
Mob. 0777 451 4488
Beauty is in the Eye of the Beholder
while Excellence is in the Hand of the Professional
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+- Sent on behalf of Choctaw Media Ltd -+-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choctaw Media Limited is a company
registered in England and Wales
with company number 04627649
Registered Office:
Lonsdale Partners,
Priory Close,
St Mary's Gate,
Lancaster LA1 1XB
United Kingdom
From: Roberto Modica
Date: Fri, Mar 16 2007 1:50AM
Subject: Re: help with a form please
← Previous message | Next message →
Hi Chirs just by briefly looking over the code, it looks fine. I only have
an issue with the use of a table (an this is my opinion) sometimes they do
not linearise in screen readers that well, and this is something you should
check. I have written a little article about forms accessibility, hopefully
that may give you some more ideas.
http://www.modika.co.uk/Articles/increasing-form-accessibility.html
HTH Rob
From: Chris Price
Date: Fri, Mar 16 2007 2:20AM
Subject: Re: help with a form please
← Previous message | Next message →
Roberto Modica wrote:
> Hi Chirs just by briefly looking over the code, it looks fine. I only have
> an issue with the use of a table (an this is my opinion) sometimes they do
> not linearise in screen readers that well, and this is something you should
> check. I have written a little article about forms accessibility, hopefully
> that may give you some more ideas.
>
> http://www.modika.co.uk/Articles/increasing-form-accessibility.html
>
>
Thanks for the information.
I am aware of the issues and solutions you outline in your article and
I, personally, would not use a table for a form if I could possibly help
it. However, I would not really have answered the question if I hadn't
used a table and I was attempting to address making tables as accessible
as possible by helping screen readers make sense of the information.
I do have one question though:
If I have a table full of tick boxes with <th> cells at the top and left
indicating scope but with no labels (as there is no text to wrap the
label around) how will someone using a screen reader deal with this?
And what about labels and <select> and <textarea>?
Kind Regards
--
Chris Price
Choctaw
= EMAIL ADDRESS REMOVED =
http://www.choctaw.co.uk
Tel. 01524 825 245
Mob. 0777 451 4488
Beauty is in the Eye of the Beholder
while Excellence is in the Hand of the Professional
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+- Sent on behalf of Choctaw Media Ltd -+-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choctaw Media Limited is a company
registered in England and Wales
with company number 04627649
Registered Office:
Lonsdale Partners,
Priory Close,
St Mary's Gate,
Lancaster LA1 1XB
United Kingdom
From: Alastair Campbell
Date: Fri, Mar 16 2007 2:40AM
Subject: Re:
← Previous message | Next message →
Hi Tedd,
I think there are a few false assumptions here, I'll try to clarify:
Firstly, I'm not being critical of your CAPTCHA methods, it's great that
someone is making some progress. However, I don't think that sites in
general should use them because including accessible CAPTCHAs is too
complex, for the user as well as developer. If they were to be taken on
by big providers, that would be better than their current methods.
> As for AOL and M$, I may be mistaken, but I seriously doubt that they
> will provide anything leading edge.
Possibly not, but the point is that they are large organisations and
could provide offline methods of creating an account.
> That's part of the problem -- a user may have to register with
> several providers to cover all the places where s/he may want to post.
The whole point of OpenID is to prevent that. If you have an AOL account
(right now, it already works), you use it with *any site* that supports
OpenID.
Simon Willison has been leading the charge on this, it's worth looking
into:
http://simonwillison.net/tags/openid/
> 1. The user wants to logon to a blog and post.
>
> 2. Blog owners want only legitimate users to post.
>
> Legitimacy is defined as a user having their own web site or a place
> where they can store a verifiable key. The key need not be a secret
> nor permanent -- but only needs to be tied to a url temporarily.
>
> How would this work?
On Simon's blog for example, I would put in my name and URL
(alastairc.ac), I would be re-directed to MyOpenID where I log in (if I
have been inactive for 20 minutes since my last login), and I get taken
back to Simon's site where I can freely post comments.
If I've used another OpenID site in that session, I wouldn't even notice
the login check, and I wouldn't have to login at my OpenID provider.
See this for how to use your own site for your openid:
http://simonwillison.net/2006/Dec/19/openid/
Your clearing house example sounds similar to a public-private key
mechanism, which would be great for people with sites, but not much use
to regular people who just want to use their AOL/MS/Yahoo account on any
site.
> The upside is that spammy probably won't want to go through the
> trouble. And, I don't see an automated way to do this.
>
> Am I wrong?
Probably not, but I don't see regular users doing that either, which is
essentially the same issue I have with CAPTCHAs.
There are some problems with OpenID (primarily phishing potential), and
it isn't the whole answer (http://simonwillison.net/2007/Feb/25/six/),
but it does seem to be the starting point for the solution.
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: Roberto Modica
Date: Fri, Mar 16 2007 2:50AM
Subject: Re: help with a form please
← Previous message | Next message →
Hi Chris,
I cant really picture that table in my head, have you got an example?
Rob
Roberto Modica wrote:
> Hi Chirs just by briefly looking over the code, it looks fine. I only
have
> an issue with the use of a table (an this is my opinion) sometimes they do
> not linearise in screen readers that well, and this is something you
should
> check. I have written a little article about forms accessibility,
hopefully
> that may give you some more ideas.
>
> http://www.modika.co.uk/Articles/increasing-form-accessibility.html
>
>
Thanks for the information.
I am aware of the issues and solutions you outline in your article and
I, personally, would not use a table for a form if I could possibly help
it. However, I would not really have answered the question if I hadn't
used a table and I was attempting to address making tables as accessible
as possible by helping screen readers make sense of the information.
I do have one question though:
If I have a table full of tick boxes with <th> cells at the top and left
indicating scope but with no labels (as there is no text to wrap the
label around) how will someone using a screen reader deal with this?
And what about labels and <select> and <textarea>?
Kind Regards
--
Chris Price
Choctaw
= EMAIL ADDRESS REMOVED =
http://www.choctaw.co.uk
Tel. 01524 825 245
Mob. 0777 451 4488
Beauty is in the Eye of the Beholder
while Excellence is in the Hand of the Professional
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+- Sent on behalf of Choctaw Media Ltd -+-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choctaw Media Limited is a company
registered in England and Wales
with company number 04627649
Registered Office:
Lonsdale Partners,
Priory Close,
St Mary's Gate,
Lancaster LA1 1XB
United Kingdom
From: Joshue O Connor
Date: Fri, Mar 16 2007 3:00AM
Subject: Re:
← Previous message | Next message →
Alastair Campbell wrote:
>> Simon Willison has been leading the charge on this, it's worth looking
> into:
> http://simonwillison.net/tags/openid/
Thanks for the heads up on OpenID's.
Cheers
Josh
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Jukka K. Korpela
Date: Fri, Mar 16 2007 3:10AM
Subject: Re: help with a form please
← Previous message | Next message →
On Fri, 16 Mar 2007, Chris Price wrote:
> If I have a table full of tick boxes with <th> cells at the top and left
> indicating scope but with no labels (as there is no text to wrap the
> label around) how will someone using a screen reader deal with this?
This has been discussed on the list at least once, with no consensus. My
advice is that such constructs should not be created. Instead of creating
a matrix of "tick boxes" (radio buttons and checkboxes), either attach a
label to each of them so that you have
Bla bla bla? ( ) agree, ( ) dunno, ( ) don't agree
or (better still) use a text input box:
Bla bla bla? [ ]
where [ ] indicates a 1-character text input box where the user can type
e.g. "Y", "N", or "-". Then the question should be marked up as label for
the field. This approach has several _other_ accessibility benefits too.
It also makes it _more evident_ to the person designing form processing
that all data shall be checked server-side. The drawback is that the user
may mistype and the error would be reported on form submission only,
unless you add JavaScript code to do preliminary checks on the fly.
> And what about labels and <select> and <textarea>?
That shouldn't be a problem. Those elements should have labels, and it is
usuall obvious which text should be wrapped inside <label> markup, e.g.
<label for="comm">Your comments:</label><br>
<textarea id="comm" rows="20" cols="50">
For <select>, don't worry about labelling <option>s. They cannot be
labelled, and need not be labelled. In non-visual browsing, the browser
will present the options to the user and let the user select among them.
Just make sure that the <option> contents are informative and
human-oriented, not machine-oriented codes. In a sense, the _content_ of
the <option> element works as a label for the associated internal,
machine-processable _value_ associated with it, e.g.
<option value="USD">US dollar</option>
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Chris Price
Date: Fri, Mar 16 2007 3:20AM
Subject: Re: help with a form please
← Previous message | Next message →
Roberto Modica wrote:
> Hi Chris,
>
> I cant really picture that table in my head, have you got an example?
>
> Rob
> Roberto Modica wrote:
>
I can't show you the page but here's a snippet:
=======================
<table>
<colgroup />
<colgroup />
<colgroup span="6" />
<colgroup />
<thead>
<tr>
<th scope="colgroup" rowspan="2">Category</th>
<th scope="colgroup" rowspan="2">Design Description</th>
<th scope="colgroup" colspan="6">Colour Choice</th>
</tr>
<tr>
<th scope="col">Black</th><th scope="col">Blue</th>
<th scope="col">Red</th><th scope="col">White</th>
<th scope="col">Green</th><th scope="col">Yellow</th>
</tr>
</thead>
<tbody>
<tr>
<td><select name="category[0]">
<option>Punk/New Wave</option>
<option>Etc.</option>
</select></td>
<td><input type="text" size="30" name="design[0]" value="" /></td>
<td><input type="checkbox" name="black[0]" value="1" /></td>
<td><input type="checkbox" name="blue[0]" value="1" /></td>
<td><input type="checkbox" name="red[0]" value="1" /></td>
<td><input type="checkbox" name="white[0]" value="1" /></td>
<td><input type="checkbox" name="green[0]" value="1" /></td>
<td><input type="checkbox" name="yellow[0]" value="1" /></td>
</tr>
=======================
Kind Regards
--
Chris Price
Choctaw
= EMAIL ADDRESS REMOVED =
http://www.choctaw.co.uk
Tel. 01524 825 245
Mob. 0777 451 4488
Beauty is in the Eye of the Beholder
while Excellence is in the Hand of the Professional
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+- Sent on behalf of Choctaw Media Ltd -+-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choctaw Media Limited is a company
registered in England and Wales
with company number 04627649
Registered Office:
Lonsdale Partners,
Priory Close,
St Mary's Gate,
Lancaster LA1 1XB
United Kingdom
From: Chris Price
Date: Fri, Mar 16 2007 3:30AM
Subject: Re: help with a form please
← Previous message | Next message →
Jukka K. Korpela wrote:
> In a sense, the _content_ of the <option> element works as a label
> for the associated internal, machine-processable _value_ associated
> with it, e.g.
> <option value="USD">US dollar</option>
>
That's a good point. I have often done this to make life easier for the
user without seeing it as an accessibility feature.
Much of this comes down to common sense (not as common as it should be).
Kind Regards
--
Chris Price
Choctaw
= EMAIL ADDRESS REMOVED =
http://www.choctaw.co.uk
Tel. 01524 825 245
Mob. 0777 451 4488
Beauty is in the Eye of the Beholder
while Excellence is in the Hand of the Professional
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+- Sent on behalf of Choctaw Media Ltd -+-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choctaw Media Limited is a company
registered in England and Wales
with company number 04627649
Registered Office:
Lonsdale Partners,
Priory Close,
St Mary's Gate,
Lancaster LA1 1XB
United Kingdom
From: Carla Hawks
Date: Fri, Mar 16 2007 1:20PM
Subject: Re: help with a form please
← Previous message | Next message →
Cheryl
I have just completed a form like you are describing. You may look at the
source code:
http://www.csufresno.edu/ccchhs/institutes_programs/CVHPI/activities/leaderE
val.shtml
Good luck,
Carla
From: Cheryl Amato
Date: Fri, Mar 16 2007 1:30PM
Subject: help with a form please
← Previous message | Next message →
Okay. Taking a hint from Chris's example I created this code. Basically, I'm using an invisible image and giving it the <label> for those input fields with no text label. I would love to re-write this entire form (no tables, css, etc) but don't have that option. They really want it to look exactly like it currently does.
So my question is - is this format understandable?
<table border="0">
<tr>
<td colspan="2"><b>Candidate:</b></td>
</tr>
<tr>
<td><input type="radio" name="ctrecipient" value="ct_acct" id="ct_acct"> <label for="ct_acct">Committee:</label></td>
<td><label for="iacct_name"><img src="clear.gif" alt="name" /></label> <INPUT size="25" name="iacct_name" ID="iacct_name"></td>
</tr>
<tr>
<td colspan="2">or</td>
</tr>
<tr>
<td><input type="radio" name="ctrecipient" value="ct_nm" id="ct_nm"> <label for="ct_nm">Candidate:</label> </td>
<td>
<table border="0">
<tr>
<td><label for="icand_fname">First Name:</label> </td>
<td><label for="icand_lname">Last Name:</label> </td>
</tr>
<tr>
<td><INPUT size="25" name="icand_fname" ID="icand_fname"></td>
<td><INPUT size="25" name="icand_lname" ID="icand_lname"></td>
</tr>
</table>
</td>
</tr>
Thanks for all your help.
Cheryl Amato
Trusted Technologies
From: Geoff Munn
Date: Sat, Mar 17 2007 1:20AM
Subject: Re: help with a form please
← Previous message | Next message →
On 17/03/2007, at 9:17 AM, Cheryl Amato wrote:
<snip>
> <td><label for="iacct_name"><img src="clear.gif" alt="name" /></
> label> <INPUT size="25" name="iacct_name" ID="iacct_name"></td>
There is no width and height attributes on your <img> element here,
which might be a problem for any accessibility guidelines you have to
conform to.
Secondly, you do not have a default value for your <input> element.
>
> <td><INPUT size="25" name="icand_fname" ID="icand_fname"></td>
> <td><INPUT size="25" name="icand_lname" ID="icand_lname"></td>
There is no 'type' attribute for these <input> elements... I presume
you mean 'text'. If so, there is also no default value.
I might be a little harsh, but there you go...
Geoff
From: Jukka K. Korpela
Date: Sat, Mar 17 2007 4:40AM
Subject: Re: help with a form please
← Previous message | Next message →
On Sat, 17 Mar 2007, Geoff Munn wrote:
> There is no width and height attributes on your <img> element here,
> which might be a problem for any accessibility guidelines you have to
> conform to.
No, width and height attributes (or corresponding CSS properties) are an
efficiency issue rather than an accessibility matter. Adding them does not
make the page any more accessible. Neither are they required or
recommended by accessibility guidelines.
In fact, they may _reduce_ accessibility. The most popular browser uses
the specified dimensions when rendering the alt text visually, in
situations where the image is not rendered. Setting pixel dimensions for
text is a potential threat, since it may result in truncation of the alt
text when it does not fit. This may happen even when the alt text is
short. After all, the user may have set his system to use a large font
in such texts (it's really a system-wide setting on Windows).
This IE behavior can be turned off, but few people ever heard of that.
> Secondly, you do not have a default value for your <input> element.
>>
>> <td><INPUT size="25" name="icand_fname" ID="icand_fname"></td>
>> <td><INPUT size="25" name="icand_lname" ID="icand_lname"></td>
Neither should there be. The old recommendation of setting dummy
placeholders as initial content was ill-advised from the beginning, and it
was made with the condition "until user agents handle empty fields
properly". The faulty browsers that didn't cope with empty fields
have lost all their significance years ago. Anyone using such a
browser these days is doomed to encounter serious difficulties in
the great majority of forms on web pages.
Following the old recommendation by foolish dummy values like VALUE="your
first name" is not only pointless; it is hostile to accessibility (e.g.,
by confusing people with cognitive problems into thinking that the field
has already been filled).
> There is no 'type' attribute for these <input> elements... I presume
> you mean 'text'. If so, there is also no default value.
There definitely is a defined default value for the type attribute in
<input> elements, and has always been ever since <input> was introduced
into HTML. The default type="text" need not be written explicitly, and it
usually isn't.
The only reason for using it is that it makes it easier to use attribute
selectors in CSS, since a selector like input[type="text"] matches
(somewhat debatably) only those <input> elements that have the attribute
value specified explicitly. But this is not an accessibility issue at all,
and it's irrelevant to most authors.
> I might be a little harsh, but there you go...
You would deserve some harsh comments for disseminating completely wrong
information, but there was nothing harsh in your style. You were just
utterly wrong and wanted to give advice before actually getting enough
advice from existing material on accessibility and web authoring.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Dejan Kozina
Date: Sat, Mar 17 2007 6:50AM
Subject: Re: help with a form please
← Previous message | Next message →
I have this bookmarked:
http://lists.w3.org/Archives/Public/w3c-wai-ig/2005JulSep/0036.html
Does anybody know more about the current state of Braille readers?
djn
Jukka K. Korpela wrote:
> Neither should there be. The old recommendation of setting dummy
> placeholders as initial content was ill-advised from the beginning, and
> it was made with the condition "until user agents handle empty fields
> properly". The faulty browsers that didn't cope with empty fields have
> lost all their significance years ago. Anyone using such a browser these
> days is doomed to encounter serious difficulties in the great majority
> of forms on web pages.
--
-----------------------------------------
Dejan Kozina Web design studio
Dolina 346 (TS) - I-34018 Italy
tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina
http://www.kozina.com/ - e-mail: = EMAIL ADDRESS REMOVED =
From: Geoff Munn
Date: Sat, Mar 17 2007 9:00PM
Subject: Re: help with a form please
← Previous message | Next message →
On 18/03/2007, at 12:32 AM, Jukka K. Korpela wrote:
> On Sat, 17 Mar 2007, Geoff Munn wrote:
>
>> There is no width and height attributes on your <img> element here,
>> which might be a problem for any accessibility guidelines you have to
>> conform to.
>
> No, width and height attributes (or corresponding CSS properties)
> are an efficiency issue rather than an accessibility matter. Adding
> them does not make the page any more accessible. Neither are they
> required or recommended by accessibility guidelines.
>
> In fact, they may _reduce_ accessibility. The most popular browser
> uses the specified dimensions when rendering the alt text visually,
> in situations where the image is not rendered. Setting pixel
> dimensions for text is a potential threat, since it may result in
> truncation of the alt text when it does not fit. This may happen
> even when the alt text is short. After all, the user may have set
> his system to use a large font
> in such texts (it's really a system-wide setting on Windows).
>
> This IE behavior can be turned off, but few people ever heard of that.
Ok, I didn't make any assertion that it was an accessibility issue, I
just referred to any 'accessibility guidelines' that the original
author may be required to comply with. If the requirement for height
and width attributes is present in such guidelines, then maybe the
guidelines are mis-named, but that doesn't make me wrong.
Here's an example:
http://www.e.govt.nz/standards/web-guidelines/web-guidelines-v-2-1/
chapter6.html
>
>> Secondly, you do not have a default value for your <input> element.
>>>
>>> <td><INPUT size="25" name="icand_fname" ID="icand_fname"></td>
>>> <td><INPUT size="25" name="icand_lname" ID="icand_lname"></td>
>
> Neither should there be. The old recommendation of setting dummy
> placeholders as initial content was ill-advised from the beginning,
> and it was made with the condition "until user agents handle empty
> fields properly". The faulty browsers that didn't cope with empty
> fields have lost all their significance years ago. Anyone using
> such a browser these days is doomed to encounter serious
> difficulties in the great majority of forms on web pages.
>
> Following the old recommendation by foolish dummy values like
> VALUE="your first name" is not only pointless; it is hostile to
> accessibility (e.g., by confusing people with cognitive problems
> into thinking that the field has already been filled).
Well you may be right, but people are still required in some cases to
comply with the old WAI priorities. If that's the case, then there
should be default values.
>
>> I might be a little harsh, but there you go...
>
> You would deserve some harsh comments for disseminating completely
> wrong information, but there was nothing harsh in your style. You
> were just utterly wrong and wanted to give advice before actually
> getting enough advice from existing material on accessibility and
> web authoring.
Not 'completely wrong' actually, you just have a very strong point of
view which is incompatible with the practicalities of what some
people are required to do. Perhaps you should try to be more
familiar with what people are required to do in the real world.
Geoff
From: Jukka K. Korpela
Date: Sat, Mar 17 2007 11:50PM
Subject: Re: help with a form please
← Previous message | Next message →
On Sun, 18 Mar 2007, Geoff Munn wrote:
> Ok, I didn't make any assertion that it was an accessibility issue, I
> just referred to any 'accessibility guidelines' that the original
> author may be required to comply with.
That's quite an explanation, isn't it?
> If the requirement for height
> and width attributes is present in such guidelines, then maybe the
> guidelines are mis-named, but that doesn't make me wrong.
> Here's an example:
> http://www.e.govt.nz/standards/web-guidelines/web-guidelines-v-2-1/
> chapter6.html
It's named "New Zealand Government Web Guidelines v2.1", and it does not
present the requirement to use width and height attributes as an
accessibility guideline at all.
> Well you may be right,
What I stated about "placeholders" is expert consensus.
> but people are still required in some cases to
> comply with the old WAI priorities.
Are they? Why do you refer to such a rule without even saying it's wrong,
when a) most web authors are _not_ required by anyone to comply with WAI
rules, b) those who are can easily find items that allow exceptions in
special cases and utilize them, and c) they can and should violate the
rules as required by accessibility when the rules are all wrong, though we
can probably allow exceptions to this if the author is in real danger of
getting prosecuted and killed for such violations, for example.
(My point is that most of the "accessibility guidelines" are just babble
and exercises in producing impressive-looking documents, to be violated in
practice even by their authors and even in the documents themselves. Few
people are forced to follow them, or even pressed hard. This is sad
because much of them is actually good advice, but this surely implies that
we need to follow the bad advice and tell our fellow authors to do so.)
> Not 'completely wrong' actually,
Well, each of the statements you made was wrong. How much more wrong can
you be?
> - - the practicalities of what some
> people are required to do.
Many web authors are required to do stupid things that are hostile to
accessibility and to disabled people. That's no excuse for misrepresenting
some rules and imaginary rules the way you did.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Geoff Munn
Date: Sun, Mar 18 2007 1:20AM
Subject: Re: help with a form please
← Previous message | No next message
On 18/03/2007, at 6:44 PM, Jukka K. Korpela wrote:
> On Sun, 18 Mar 2007, Geoff Munn wrote:
>
>> Ok, I didn't make any assertion that it was an accessibility issue, I
>> just referred to any 'accessibility guidelines' that the original
>> author may be required to comply with.
>
> That's quite an explanation, isn't it?
>
>> If the requirement for height
>> and width attributes is present in such guidelines, then maybe the
>> guidelines are mis-named, but that doesn't make me wrong.
>> Here's an example:
>> http://www.e.govt.nz/standards/web-guidelines/web-guidelines-v-2-1/
>> chapter6.html
>
> It's named "New Zealand Government Web Guidelines v2.1", and it
> does not
> present the requirement to use width and height attributes as an
> accessibility guideline at all.
Chapter 1, '1.1 Purpose':
"We provide practical ways to express these values in public sector
websites. However, we don't attempt to cover every circumstance with
a prescriptive rule. Rather, we encourage you to make sound
judgements based on an understanding and appreciation of the four
principles above, and how they can be applied to provide sound,
trustworthy and truly accessible public sector websites."
Before you seize on the words 'encourage to make sound
judgements....', I have to add that many of the rules in this
document are actually Cabinet-mandated requirements and the 'height
and width attributes' requirement is a 'must' (their words).
Department managers/CEOs must explain to the SSC why they do not
measure up against these guidelines.
>
>> Well you may be right,
>
> What I stated about "placeholders" is expert consensus.
>
>> but people are still required in some cases to
>> comply with the old WAI priorities.
>
> Are they? Why do you refer to such a rule without even saying it's
> wrong,
I'm not saying it's wrong. The WAI priorities are fundamentally
quite good, but when they get overly prescriptive (especially when
they're incorporated into other guidelines) people such as yourself
jump all over it.
> when a) most web authors are _not_ required by anyone to comply
> with WAI
> rules,
Any NZ Government web development project is required to follow
these. It's an SSC directive. The Queensland Federal Government
have their own set of requirements (which use priorities 1 and 2 -
(http://www.governmentict.qld.gov.au/02_infostand/standards/
is26.htm), so do other organisations which may or may not incorporate
the WAI prorities.
> b) those who are can easily find items that allow exceptions in
> special cases and utilize them, and c) they can and should violate the
> rules as required by accessibility when the rules are all wrong,
> though we
> can probably allow exceptions to this if the author is in real
> danger of
> getting prosecuted and killed for such violations, for example.
>
So how does government web design fit into your neat and tidy view of
the world? You won't get shot at dawn, but you won't get any
government business either.
> (My point is that most of the "accessibility guidelines" are just
> babble
> and exercises in producing impressive-looking documents, to be
> violated in
> practice even by their authors and even in the documents
> themselves. Few
> people are forced to follow them, or even pressed hard. This is sad
> because much of them is actually good advice, but this surely
> implies that
> we need to follow the bad advice and tell our fellow authors to do
> so.)
Well that may be your experience, but I've had a better time myself...
>
>> Not 'completely wrong' actually,
>
> Well, each of the statements you made was wrong. How much more
> wrong can
> you be?
I am not wrong. You just like to cast things in black and white.
>
>> - - the practicalities of what some
>> people are required to do.
>
> Many web authors are required to do stupid things that are hostile to
> accessibility and to disabled people.
That's true.
> That's no excuse for misrepresenting
> some rules and imaginary rules the way you did.
I didn't.
Geoff