Re: [WSG] Controling Windows DPI settings

2008-02-25 Thread James Ellis
Hi Angus

Do you happen to be talking to people who like itsy bitsy font sizes ? Do they 
happen to be setting their own font sizes ? I guess, find out if it is 
widespread and then consider your options. Font-size is bit like calling 
purple lavender, violet or magenta - everyone has an opinion :) I find 
sticking to the middle ground is best.

Cheers
James


On Sun, 24 Feb 2008 01:14:07 pm Hayden's Harness Attachment wrote:
 I have Windows Vista Home Premium and use 96 DPI. I am told repeteated ly
 that my fonts are to large. I have even tried font-size: 80%; in my CSS
 and still get told the fonts are to large. I know you are not able to
 overide a person's preferences. can I do something in CSS to change the
 default DPI and/or font-size? And then create different CSS files to
 increase the DPI and/or font-sizes?




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] re: generate data

2008-02-25 Thread James Ellis
Hi, inline comments ..


On Sun, 24 Feb 2008 03:02:46 pm Breton Slivka wrote:

  i understand that javascript is needed to pass information from a form to
  a data base for storage or retrieval of data.

 Incorrect- Javascript is absolutely not needed for this. In fact, I
 would actively discourage this usage, because it makes forms
 inaccessable to clients without javascript. (Even though I do quite
 like javascript most of the time)

Not all the time, I hope. If you have a submit listener on a form, those 
without JS will obviously ignore it and you can catch them for validation on 
the server side. The great majority of your browsers will process the JS 
submit listener and do client side validation. You can still catch them on 
the server side as well, if the listener allows the form to be submitted, 
using the same script as the first case, just that you are saving some 
un-necessary page loads (among other benefits).


  i also understand there are more uses for javascript than my above
  remark, but, again, my limited understanding of javascript draws a blank
  for other uses.

 Javascript is basically a tool to allow website authors to add browser
 features that are not built in to the browser. That's how I see it
 anyway. That's not exactly how most people use it, or think of it.

  i don't understand why someone would code a page and use javascript that
  would make the page not available without it.

Think about the intended audience of the site in question. Can you think of a 
developer that would want to use this tool, particularly one who can install 
and run a PHP app, that wouldn't have JS enabled and if not, wouldn't know 
how to enable it?
If they were making a site for pensioners to update their home insurance, for 
sure it's the wrong way to do things but in this case it's absolutely 
appropriate.

My concern is more about the scoring with girls comment which points to 
someone who really needs assistance accessing some natural light rather than 
better html. :)

Cheers
J


 It's not strictly the usage of javascript that makes the page
 inaccessable, it's the page's dependance on it. If you think of
 javascript like I do- A tool for adding features- then the page still
 needs to be able to work without those features. The reasons for
 someone making a page that doesn't work without javascript are
 complicated, but it basically boils down to how the author thinks
 about what a webpage is, and how it works.




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] form problem

2008-02-25 Thread Michael Horowitz
I hadn't realized I had the link break. I had also had an issue where 
their were additional spaces between textarea and main.  I thought 
whitespace didn't matter for xhtml though.


Question anyone see why the textarea is showing up on a different line 
than the label. Everywhere else it lines up correctly.  It doesn't seem 
that I am out of space.  It looks ok in Dreamweaver but the problem 
occurs in both IE and Firefox.  (And yes I will fix the other label 
issues people pointed out for accessibility later today)



Michael Horowitz
Your Computer Consultant
http://yourcomputerconsultant.com
561-394-9079



Thierry Koblentz wrote:

On Behalf Of Jason Gray
Michael

Your current code is

label for=commentsComments:/label
textarea name=comments rows=6 cols=40
  /textarea

It should be

label for=commentsComments:/label
textarea name=comments rows=6 cols=40/textarea



The value of the for attribute should match an *id*

  



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



[WSG] Site review

2008-02-25 Thread Andrew Maben
I'm almost done with a site redesign, and the time is right to ask  
for your opinions: http://beta.www.aclib.us

for comparison, the current site is: http://www.aclib.us

I'm aiming for HTML 4.01 Strict compliance, and am periodically  
running the W3C Validator, so no need to notify me of validation errors.


Of course accessibility is important, and this is where your insights  
and criticisms can be especially helpful.


There's some use of Javascript, mostly to show/hide content - I'm  
finishing up some changes to remove the JS dependency for these  
enhancements, (but I'm still using onClick which I'll be replacing  
as soon as I get a chance - deadline compromise...)


I'm not thrilled with the IA, and though changes may be hard to sell  
or implement, I'd welcome any reasoned criticism on this front.


I have yet to write the CSS for print and for mobile devices, and  
would welcome suggestions here too, as well as from iPhone/iPod Touch  
users.


Thanks in advance.

Andrew

http://www.andrewmaben.net
[EMAIL PROTECTED]

In a well designed user interface, the user should not need  
instructions.





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Site review

2008-02-25 Thread kate
Hi Andrew,

The site looks nice. I put the address into W3C Validator and its passed the 
4.01 Transitional but has 23 warnings..strange..

Maybe the other members can explain, anyway its  anice site and looks fine in 
FF. I am on the following:

Win XP
1680x1050
SP2
IE
Kate
Bichon Frise: http://jungaling.com/kynismarmissmillie/

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***


Re: [WSG] Site review

2008-02-25 Thread dwain
On 2/25/08, Andrew Maben [EMAIL PROTECTED] wrote:

 Of course accessibility is important, and this is where your insights and
 criticisms can be especially helpful.


here's a tool to check web site accessibility:
http://www.tawdis.net/taw3/cms/en

it suggests guidelines.

dwain


-- 
dwain alford
The artist may use any form which his expression demands;
for his inner impulse must find suitable expression.  Kandinsky


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Site review

2008-02-25 Thread Tim Offenstein
I'm almost done with a site redesign, and the time is right to ask 
for your opinions: http://beta.www.aclib.ushttp://beta.www.aclib.us

for comparison, the current site is: http://www.aclib.ushttp://www.aclib.us

I'm aiming for HTML 4.01 Strict compliance, and am periodically 
running the W3C Validator, so no need to notify me of validation 
errors.


Just curious why you chose HTML instead of XHTML. Personally I like 
XHTML 1.0 Transitional.



Of course accessibility is important, and this is where your insights 
and criticisms can be especially helpful.


Using the Functional Accessibility Evaluator 
(http://fae.cita.uiuc.edu), there are minor issues:

1. The best practice recommendation is that your H1 tag match you page title.
2. Your form control for the Search should have a label element 
associated with them.
3. Pretty good use of header mark up. In conjunction with this, it is 
generally recommended your Primary Navigation should be an unordered 
list rather than a definition list and should be preceded by a header 
tag. That way disabled users can navigate to the list by headers and 
therefore Skip nav links are not necessary.

4. The alt tag for the WebFeat jpg should have some content.
5. Use of the i tag (on African-American History Online), should be 
replaced with em. Use of the i tag is considered deprecated 
because it is more presentation markup than semantic.

6. Your page should declare a language type. This goes in the HTML element.

Everything else looks good with the one caveat that the 36px for 
catSearchLabel is overkill. Besides the point that font-sizes should 
always be in ems or %.) Do you really want it to be that predominant? 
It also quickly overwhelms the page when the user has to bump up the 
other font sizes. Also if you do want it predominant, I suggest 
making Search a header tag rather than a styled paragraph. That way 
it maintains its importance when CSS is removed.


One free tidbit - try the Firefox Accessibility Extension 
(https://addons.mozilla.org/en-US/firefox/addon/1891) This is a great 
toolbar for testing your page to see how accessible it is.


Best regards,

-Tim
--

   Tim Offenstein  ***  Campus Accessibility Liaison  ***  (217) 244-2700
CITES Departmental Services  ***  www.uiuc.edu/goto/offenstein


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Site review

2008-02-25 Thread Robert O'Rourke
No big layout issues at all but on a quick perusal there are few things 
I've noticed:


The stripey background - close thin stripes get flickery and a bit 
distracting when the page is scrolled


IE:
   - the search area needs some cross-browser attention. font-sizes, 
input widths and the submit button padding are a bit dicey (but at least 
similar in IE).


   - the text 'Search:' has lost the clear-type filter that IE7 
imposes. I only know of this to happen when another IE CSS filter is 
applied to the element or its parent. Typically it's the opacity filter 
that's the culprit but it doesn't look like you've used that and I don't 
know off the top of my head what else causes it.


-Rob


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Site review

2008-02-25 Thread tee


On Feb 25, 2008, at 10:47 AM, Robert O'Rourke wrote:

No big layout issues at all but on a quick perusal there are few  
things I've noticed:


The stripey background - close thin stripes get flickery and a bit  
distracting when the page is scrolled


Same here. I find the background distracting. Another thing is  the  
lack of spacing in areas such as menus, headings, paragraphs and  
images. E.g. increasing the padding top/bottom for all menus; add  
padding left for h2 to h6; add padding left for p or margin right/ 
bottom for the image floated left and margin left/bottom for image  
floated right; give padding or margin top for logo and skip to main  
content.


Appropriate spacing around content blocks really can make a site looks  
so much user-friendly and nice looking, and visually, more accessible  
for the eyes. It seems to me a common oversight by the web developers  
who are more programming and technically savvy, but in my humble  
opinion, one doesn't need to have a graphic design degree to  
appreciate the need for spacing. Just think of the feelings you have  
being in the crowd and in the open space, you can easily see the  
difference it can make for a site without spacing.


Cheers,

tee


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] re: generate data

2008-02-25 Thread tee
Hi, I really enjoyed reading this thread, especially the responses  
from Georg and Breton, and thank you Dwain for asking the question.


I have heard a lot about unobtrusive js but thus far it's more like a  
buzzword to me because I understand no JS.


Can one recommend which JS library is more accessibility user-friendly  
(is there such word?!). I know the jquery, mootool, prototype, Dojo,  
Extjs, YUI libraries, and have recently used the jquery for accordion  
menu  and prototype for glider (sliding gallery like the one in  
Panic.com), but I don't know enough to settle for one that is  
relatively small size and unobtrusive. Everybody claims he is  
unobtrusive, and I have difficulty to settle down with one.


Thanks!

tee
On Feb 24, 2008, at 4:56 AM, Gunlaug Sørtun wrote:


dwain wrote:

if accessibility isn't cracked up to what it's supposed to be, then  
why are there laws about the subject?


The laws are probably there to prevent accessibility from falling
through the cracks. Consciously or unconsciously ignoring access for
all is after all more the norm than the exception, and that has to  
change.


The two levels of accessibility have been mention.

- The first level, where access to content and functionality should be
guaranteed on a technical level, is not much of a problem. Basic
understanding of how to build a site is all that's required to reach
that level.

The challenged user-groups I ask for advice, expect me to meet  
them at
that level - which is (slowly being) required by law for public  
sites in

my country anyway.



- The second level, where some kind of optimizing for specific
user-groups and their hardware/software solutions has to take place,  
is

of course harder.

I'm being told *not to go there* by the same challenged user-groups,
as more accessible solutions for smaller groups may end up being
tied to some weak end-user solutions that should rather be
upgraded/replaced and brought in line with the technical level  
most of
them are comfortable with. They work for improvements and solutions  
that

are tailor-made to the individual's needs - at their end, based on
common delivery-methods and techniques that can be made to work for  
all

- as long as we developers/designers don't get in their way.

A requirement for common delivery-methods and techniques is being
introduced by law in my country now anyway - for public sites, which
should mean solutions at the user-end will make the need for more
accessible solutions at our end a non-issue over time - in Norway.



What kind of leveling that is missing/introduced/necessary in other
parts of the world is somewhat unknown to me, but providing accessible
solutions on a technical level - and pretty much limit it to that,  
is

the only common and sensible approach if we want some progress, IMO.
Promoting the need for accessible solutions on a technical level on
top of existing and future web standards, should keep us busy enough  
for

quite a while.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] re: generate data

2008-02-25 Thread Thierry Koblentz
 Hi, I really enjoyed reading this thread, especially the responses
 from Georg and Breton, and thank you Dwain for asking the question.
 
 I have heard a lot about unobtrusive js but thus far it's more like a
 buzzword to me because I understand no JS.

I wrote an article that gives the basic picture:
http://www.tjkdesign.com/articles/semantics_unobtrusive-scripting_and_beyond
.asp


-- 
Regards,
Thierry | http://www.TJKDesign.com






***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] Site review

2008-02-25 Thread Thierry Koblentz
It looks good, but I'd agree with Tee, it needs some spacing.

Interesting use of DLs, but I would not use display:none to hide the DT
(shoot them off-screen).

Also, I'd get rid of the DIV wrappers you have around these DLs. I think you
could remove a few other DIVs from the markup.

If the large image in the Hot Topics section has an empty alt attribute, why
not using it as a background image? Right now you have it wrapped in a div
that is floated right and that image inside is floated *left* (?) with extra
margin values.

I'm not sure what you're doing with the P before the H1, I think you could
achieve the same thing using a real image in that H1 [1]

I'd style the skip nav on focus, because that link is very small and the
outline barely shows

 

[1] http://www.tjkdesign.com/articles/tip.asp

 

-- 

Regards,

Thierry | http://www.TJKDesign.com

 

 

 

 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Andrew Maben
Sent: Monday, February 25, 2008 7:32 AM
To: wsg@webstandardsgroup.org
Subject: [WSG] Site review

 

I'm almost done with a site redesign, and the time is right to ask for your
opinions: http://beta.www.aclib.us

for comparison, the current site is: http://www.aclib.us

 

I'm aiming for HTML 4.01 Strict compliance, and am periodically running the
W3C Validator, so no need to notify me of validation errors.

 

Of course accessibility is important, and this is where your insights and
criticisms can be especially helpful.

 

There's some use of Javascript, mostly to show/hide content - I'm finishing
up some changes to remove the JS dependency for these enhancements, (but I'm
still using onClick which I'll be replacing as soon as I get a chance -
deadline compromise...)

 

I'm not thrilled with the IA, and though changes may be hard to sell or
implement, I'd welcome any reasoned criticism on this front.

 

I have yet to write the CSS for print and for mobile devices, and would
welcome suggestions here too, as well as from iPhone/iPod Touch users.

 

Thanks in advance.

 

Andrew

 

 http://www.andrewmaben.com/ http://www.andrewmaben.net

 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]

 

In a well designed user interface, the user should not need instructions.





 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*** 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread tee
I have this question about strong element being more semantical and  
accessible for required field in the web form and like to hear your  
opinion.


I came to the conclusion after conducting my little user testing - it  
first started with an intention of spam and error monitoring over the  
form script I use, I then learned that despite the indication that  
asterisk is marked as  required field, many people who took time to  
submit the forms on clients' sites  still missed the *.  Because I  
use no JS validation for the form, I decided to bold the required  
field using strong element for two new sites. It seems working as the  
bold texts caught people attention and I received no errors email  
notification on missing to enter requried fields. The result also gave  
me a though on how screen readers treat the strong element and that  
it's indeed more accessible and semantically correct.


Working on a site, and thanks to Matt Fellows and his futher  
assistance, I implemented his JS form validation script to the web  
form. Using asterik  to indicate the required field no longer is an  
issue with JS validation, however I decided to stick with the strong  
element. Much work had put into it to modify the code and css, but  
client came back to me to want the '*' over the strong because it's  
a conventional practice.


Really want to stick with the strong element for the reason above,  
however I am also doubting  my conclusion that it's more accessible  
for screen readers as I never tested on one. Before I try to convince  
client the strong element is better approach, I would love to hear  
your opinion.


Thank you!

tee


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] re: generate data

2008-02-25 Thread Ray Leventhal

tee wrote:
Hi, I really enjoyed reading this thread, especially the responses from 
Georg and Breton, and thank you Dwain for asking the question.


I have heard a lot about unobtrusive js but thus far it's more like a 
buzzword to me because I understand no JS.


Can one recommend which JS library is more accessibility user-friendly 
(is there such word?!). I know the jquery, mootool, prototype, Dojo, 
Extjs, YUI libraries, and have recently used the jquery for accordion 
menu  and prototype for glider (sliding gallery like the one in 
Panic.com), but I don't know enough to settle for one that is relatively 
small size and unobtrusive. Everybody claims he is unobtrusive, and I 
have difficulty to settle down with one.


Thanks!

Hi tee,

An interesting thread indeed.

I can't recommend any JS libraries as I'm only now cutting my teeth on 
JS, but I can wholeheartedly recommend a book on JS which focuses on 
graceful degradation and manipulation of the DOM:


DOM Scripting: Web Design with JavaScript and the Document Object Model 
 by Jeremy Keith



HTH,
-Ray



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Jason Pruim


On Feb 25, 2008, at 3:34 PM, tee wrote:

I have this question about strong element being more semantical and  
accessible for required field in the web form and like to hear your  
opinion.


I came to the conclusion after conducting my little user testing -  
it first started with an intention of spam and error monitoring over  
the form script I use, I then learned that despite the indication  
that asterisk is marked as  required field, many people who took  
time to submit the forms on clients' sites  still missed the *.   
Because I use no JS validation for the form, I decided to bold the  
required field using strong element for two new sites. It seems  
working as the bold texts caught people attention and I received no  
errors email notification on missing to enter requried fields. The  
result also gave me a though on how screen readers treat the strong  
element and that it's indeed more accessible and semantically correct.


Working on a site, and thanks to Matt Fellows and his futher  
assistance, I implemented his JS form validation script to the web  
form. Using asterik  to indicate the required field no longer is  
an issue with JS validation, however I decided to stick with the  
strong element. Much work had put into it to modify the code and  
css, but client came back to me to want the '*' over the strong  
because it's a conventional practice.


Really want to stick with the strong element for the reason above,  
however I am also doubting  my conclusion that it's more accessible  
for screen readers as I never tested on one. Before I try to  
convince client the strong element is better approach, I would love  
to hear your opinion.



I can't speak for screen readers since I've never used one my self...  
But would there be any reason you couldn't do both and please the  
client and the screen reader(assuming it does help them)? a simple  
strong* First Name/strong


Just something I thought of :)


--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
[EMAIL PROTECTED]





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread russ - maxdesign
 I can't speak for screen readers since I've never used one my self...
 But would there be any reason you couldn't do both and please the
 client and the screen reader(assuming it does help them)? a simple
 strong* First Name/strong
 
 Just something I thought of :)

Interesting discussion. You could also use more meaningful flags like the
word Required instead of * and style this content in red/bold. This
means that everyone, including screen reader users understand the
implications much more clearly (as long as this information is included
inside the label element.

For example:

label for=details-email
Email span class=required(Required)/span:
/label

Or...

label for=details-email
Email strong(Required)/strong:
/label

Then you could easily style it with something like:

label strong  (or label span.required)
{
color: red;
font-weight: bold
text-transform: uppercase;
font-size: 85%;
}

You can even position this required content after the input element
using absolute positioning as Derek Featherstone has proposed.

HTH
Russ





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] form problem

2008-02-25 Thread Rob Unsworth
On Mon, 25 Feb 2008, Michael Horowitz wrote:

 Question anyone see why the textarea is showing up on a different line than
 the label. Everywhere else it lines up correctly. 

The following works.

br /  -- changed from p/p
p class=comments
label for=commentsComments:/label
textarea name=comments rows=6 cols=35/textarea --Cols now 35
/p






-- 
Regards,  | Lions District 201 Q3
Rob Unsworth  | IT  Internet Chairman
Ipswich, Australia| http://www.lionsq3.asn.au
-



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Matt Fellows
Interesting indeed!

Actually Tee I was going to pose the same question to the list
following our discussions the other day :) I would like to get it
right in GValidator so the core doesn't need to be modified by clients
such as yourself.

I would like to see the results of reliable and publicly available
research. Does anyone know of any? A quick Google search doesn't turn
up anything overly exciting or empirical.
Maybe we can do some testing of our own?

So there are actually three interrelated things here: The first is the
semantics of the span class=required*/span element, then there
is the usability and accessibility of it's use.

In terms of usability and accessibility, my initial thoughts would be
that given a sufficiently prominant key just before and in close
proximity to the form, that sighted users should have no problem
identifying which form elements need to be filled in. Users with
screen readers however might have a little more trouble with this
approach, so an approach similar to Russ's suggestion seems like the
best approach.

In terms of semantics, w3c says this about the strong element:
The strong element indicates higher importance for its contents than
that of the surrounding content.

I am unsure as to if it is more important that the label? But I can
see a clear benefit for blind users. So what do we do?

Cheers,

Matt

P.S. Although a while away, we do have these sorts of things to look forward to:
* http://www.w3.org/TR/2008/WD-html5-diff-20080122/#new-attributes
* http://www.w3.org/TR/WCAG20-TECHS/ARIA2.html

On 2/26/08, russ - maxdesign [EMAIL PROTECTED] wrote:
  I can't speak for screen readers since I've never used one my self...
   But would there be any reason you couldn't do both and please the
   client and the screen reader(assuming it does help them)? a simple
   strong* First Name/strong
  
   Just something I thought of :)


 Interesting discussion. You could also use more meaningful flags like the
  word Required instead of * and style this content in red/bold. This
  means that everyone, including screen reader users understand the
  implications much more clearly (as long as this information is included
  inside the label element.

  For example:

  label for=details-email
 Email span class=required(Required)/span:
  /label

  Or...

  label for=details-email
 Email strong(Required)/strong:
  /label

  Then you could easily style it with something like:

  label strong  (or label span.required)
  {
 color: red;
 font-weight: bold
 text-transform: uppercase;
 font-size: 85%;
  }

  You can even position this required content after the input element
  using absolute positioning as Derek Featherstone has proposed.

  HTH

 Russ






  ***
  List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
  Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
  Help: [EMAIL PROTECTED]
  ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] form problem

2008-02-25 Thread David Dorward


On 25 Feb 2008, at 22:46, Rob Unsworth wrote:

br /  -- changed from p/p
p class=comments


A line break immediately before a paragraph doesn't make sense. You  
probably should be using a margin instead.


A form control and its label don't really qualify as a paragraph, a  
div is probably a better bet.



label for=commentsComments:/label
textarea name=comments rows=6 cols=35/textarea --Cols  
now 35


The for attribute of a label refers to the id attribute of a form  
control, your id attribute is missing.

--
David Dorward
http://dorward.me.uk/
http://blog.dorward.me.uk/




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Thierry Koblentz
 On Behalf Of russ - maxdesign
 Sent: Monday, February 25, 2008 1:37 PM
 To: Web Standards Group
 Subject: Re: [WSG] strong element being more semantical and accessible for
 required field
 
  I can't speak for screen readers since I've never used one my self...
  But would there be any reason you couldn't do both and please the
  client and the screen reader(assuming it does help them)? a simple
  strong* First Name/strong
 
  Just something I thought of :)
 
 Interesting discussion. You could also use more meaningful flags like the
 word Required instead of * and style this content in red/bold. This
 means that everyone, including screen reader users understand the
 implications much more clearly (as long as this information is included
 inside the label element.
 
 For example:
 
 label for=details-email
 Email span class=required(Required)/span:
 /label

What about using a fieldset with *legend* if the required fields can be
grouped together.
Because the legend (required fields) would be read aloud before each label.


-- 
Regards,
Thierry | http://www.TJKDesign.com







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Matt Fellows
 What about using a fieldset with *legend* if the required fields can be
  grouped together.
  Because the legend (required fields) would be read aloud before each label.

I thought about this, but I think it makes more sense to have related
elements grouped together and in most cases not all of these will be
required.

For example, many forms ask for personal details such as addresses,
phone numbers, work details etc. Not all will be mandatory, but it
definately makes sense to group these together.

I think it might be a little confusing to enter in details out of
order, especially if the form is broken over several pages (have I
already entered this information?).

Cheers,

Matt


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Darren Lovelock
I believe a more semantically correct method would be to use strong:

label for=details-email
Email: strong(Required)/strong
/label 

Darren Lovelock
Munky Online Web Design
http://www.munkyonline.co.uk
T: +44 (0)20-8816-8893


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Thierry Koblentz
Sent: 26 February 2008 00:02
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] strong element being more semantical and accessible for
required field

 On Behalf Of russ - maxdesign
 Sent: Monday, February 25, 2008 1:37 PM
 To: Web Standards Group
 Subject: Re: [WSG] strong element being more semantical and accessible 
 for required field
 
  I can't speak for screen readers since I've never used one my self...
  But would there be any reason you couldn't do both and please the 
  client and the screen reader(assuming it does help them)? a simple
  strong* First Name/strong
 
  Just something I thought of :)
 
 Interesting discussion. You could also use more meaningful flags like 
 the word Required instead of * and style this content in red/bold. 
 This means that everyone, including screen reader users understand the 
 implications much more clearly (as long as this information is 
 included inside the label element.
 
 For example:
 
 label for=details-email
 Email span class=required(Required)/span:
 /label

What about using a fieldset with *legend* if the required fields can be
grouped together.
Because the legend (required fields) would be read aloud before each label.


--
Regards,
Thierry | http://www.TJKDesign.com







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Jixor - Stephen I

What about abbr title=Required*/abbr?

tee wrote:
I have this question about strong element being more semantical and 
accessible for required field in the web form and like to hear your 
opinion.


I came to the conclusion after conducting my little user testing - it 
first started with an intention of spam and error monitoring over the 
form script I use, I then learned that despite the indication that 
asterisk is marked as  required field, many people who took time to 
submit the forms on clients' sites  still missed the *.  Because I 
use no JS validation for the form, I decided to bold the required 
field using strong element for two new sites. It seems working as the 
bold texts caught people attention and I received no errors email 
notification on missing to enter requried fields. The result also gave 
me a though on how screen readers treat the strong element and that 
it's indeed more accessible and semantically correct.


Working on a site, and thanks to Matt Fellows and his futher 
assistance, I implemented his JS form validation script to the web 
form. Using asterik  to indicate the required field no longer is an 
issue with JS validation, however I decided to stick with the strong 
element. Much work had put into it to modify the code and css, but 
client came back to me to want the '*' over the strong because it's 
a conventional practice.


Really want to stick with the strong element for the reason above, 
however I am also doubting  my conclusion that it's more accessible 
for screen readers as I never tested on one. Before I try to convince 
client the strong element is better approach, I would love to hear 
your opinion.


Thank you!

tee


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***






***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Thierry Koblentz
Hi Mike,

  What about using a fieldset with *legend* if the
  required fields can be grouped together. Because
  the legend (required fields) would be read aloud
  before each label.
 
 In some cases that's an excellent solution (what I've been using for a
 while) but unfortunately power users will dial down verbosity so much that
 they will quiet legends as well.
 
 A blind power user I know told me * is best. He also told me nothing else
is
 needed, but he's a person and that part my be his opinion. For all-around
 safety, one of these might be best:
 
 label* denotes required field/label
 fieldset
 legendRequired/legend
 label for=nameName * input name=name
 label for=emailEmail * input name=email
 /fieldset
 
 fieldset
 legendRequired/legend
 label for=nameName (required) input name=name
 label for=emailEmail (required) input name=email
 /fieldset

I think using legend *and* plain text in the label may be a bit overkill.
If I get it right, best case scenario the user listens to it once, worst
case scenario the text in the label is repeated after the legend :-(
imho, if it is part of the label already, then I'd not use legend.
I don't think we should make it super safe as it could create UE issues on
its own; if only legend is used and the user misses it because of his custom
settings, then hopefully the validation routine will bring him to a place
where he'll be able to find out what went wrong.

-- 
Regards,
Thierry | http://www.TJKDesign.com





 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Patrick H. Lauke

Darren Lovelock wrote:

I believe a more semantically correct method would be to use strong:

label for=details-email
Email: strong(Required)/strong
/label 


Indeed, that's the approach I've taken in recent years. For aesthetic 
considerations, I sometimes style drop in a style like


label strong { font-weight: normal; font-size: 0.75em; }

to make it less obtrusive, but still quite readable and understandable.
It may make labels slightly longer, but on the plus side it saves those 
awful * denotes a required field explanations and is immediately obvious.


P
--
Patrick H. Lauke
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
__
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
__


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread tee


On Feb 25, 2008, at 1:05 PM, Jason Pruim wrote:


I can't speak for screen readers since I've never used one my  
self... But would there be any reason you couldn't do both and  
please the client and the screen reader(assuming it does help them)?  
a simple strong* First Name/strong


Just something I thought of :)


Hi Jason,

That was my first thought for a quick fix actually :)

I thought  strong* First Name/strong is a bit too excessive. Will  
the screen reader reads  out asterisk strong? That maybe annoying  
for the ears.


tee


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread tee


On Feb 25, 2008, at 4:55 PM, Darren Lovelock wrote:


I believe a more semantically correct method would be to use strong:

label for=details-email
Email: strong(Required)/strong
/label


Same here.

One of the reason I dislike using fieldset is that FF and IE are both  
buggy with the legend. If a form needs extra visual styling, it takes  
more codes to make these two browsers behave.


tee


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Matt Fellows
 In some cases that's an excellent solution (what I've been using for a
 while) but unfortunately power users will dial down verbosity so much that
 they will quiet legends as well.

  A blind power user I know told me * is best. He also told me nothing else is
  needed, but he's a person and that part my be his opinion. For all-around
  safety, one of these might be best:

Thanks Mike that's really interesting. I would argue, based on the
anecdotal evidence you've given, that the following legend is
superflous and prevents logical grouping.

  fieldset
  legendRequired/legend
  label for=nameName (required) input name=name
  label for=emailEmail (required) input name=email
  /fieldset

I am definitely leaning toward the following:

fieldset
 legendPersonal Details/legend

 label for=nameName  span class=required(required)/span/label
 input name=name

 label for=emailEmail span class=required(required)/span/label
 input name=email

 label for=phonePhone/label
 input name=phone
 ...
/fieldset

Giving in to other's suggestions perhaps the span class=required
could become strong class=required :)

The benefits here are:
* Easily scannable for the regular user
* Will be read out for screen readers
* Semantically intact
* Inputs can be grouped logically
* No need for annoying legends

Does this seem to be a combination of the general consensus?


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Mike at Green-Beast.com

Hi Matt,


that the following legend is
superflous and prevents logical grouping.


 fieldset
 legendRequired/legend
 label for=nameName (required) input name=name
 label for=emailEmail (required) input name=email
 /fieldset


I agree, actually. With that example (and the image one I gave) using the 
word required, in the case of a user listening with a setting that reads the 
legends (default), would make it too verbose. It'd read:


Required Name Required
Required Email Required

Though I guess there'd be no missing it. ;-)

The use of the Required legend seems to work well with the asterisk, with 
its meaning defined in a non-associated label (one with no for attribute). 
It's a compromise method. I do have one form on a real-deal AAA WCAG 2.0 
site I made (to be officially announced Mar. 11-12th) with this specific 
configuration. It's open now by invite to a few disabled users/testers and a 
couple of key WCAG 2.0 Editors, and I got more very positive comments about 
that particular set-up tonight... a few minutes ago actually.



fieldset
legendPersonal Details/legend

label for=nameName  span class=required(required)/span/label
input name=name


That is a solid method for sure, but there's only one problem and that is to 
*some* users (default settings) it might sound too verbose.


Personal Details Name Required
Personal Details Email Required
Personal Details Phone

The problem is not the technique, yours or mine, or any of the other 
accessible methods. It's the myriad configurations possible that really 
challenge us. There are so many variables (not even including those of 
sighted users) that while there are a number of feasible methods, there 
seems no perfect one-size fits-all answer. It's all a compromise.


Mike



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] strong element being more semantical and accessible for required field

2008-02-25 Thread Matt Fellows
Thanks Mike. I guess I would prefer verbose and have them fill the
form out once than have them have them misinterpret and have to fix
errors, which I imagine can be tedious using a screen reader. Is this
the case?

It would be great if you could keep us posted about any feedback you
get in March when the site goes live.

For the average user however, what I think I will do is run a few
simple A\B tests on some of my sites and log the amount of JavaScript
errors for each of the different methods described (there seems to be
at least three plausible options). It will take some time to get
statistical significance however so it might be a while before I have
something useful.

Cheers,

Matt

On 2/26/08, Mike at Green-Beast.com [EMAIL PROTECTED] wrote:
 Hi Matt,


   that the following legend is
   superflous and prevents logical grouping.
  

   fieldset
legendRequired/legend
label for=nameName (required) input name=name
label for=emailEmail (required) input name=email
/fieldset


 I agree, actually. With that example (and the image one I gave) using the
  word required, in the case of a user listening with a setting that reads the
  legends (default), would make it too verbose. It'd read:

  Required Name Required
  Required Email Required

  Though I guess there'd be no missing it. ;-)

  The use of the Required legend seems to work well with the asterisk, with
  its meaning defined in a non-associated label (one with no for attribute).
  It's a compromise method. I do have one form on a real-deal AAA WCAG 2.0
  site I made (to be officially announced Mar. 11-12th) with this specific
  configuration. It's open now by invite to a few disabled users/testers and a
  couple of key WCAG 2.0 Editors, and I got more very positive comments about
  that particular set-up tonight... a few minutes ago actually.

   fieldset
   legendPersonal Details/legend

 
   label for=nameName  span class=required(required)/span/label
   input name=name


 That is a solid method for sure, but there's only one problem and that is to
  *some* users (default settings) it might sound too verbose.

  Personal Details Name Required
  Personal Details Email Required
  Personal Details Phone

  The problem is not the technique, yours or mine, or any of the other
  accessible methods. It's the myriad configurations possible that really
  challenge us. There are so many variables (not even including those of
  sighted users) that while there are a number of feasible methods, there
  seems no perfect one-size fits-all answer. It's all a compromise.


  Mike




  ***
  List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
  Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
  Help: [EMAIL PROTECTED]
  ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***