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

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 w

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

Hi Matt, that the following legend is superflous and prevents logical grouping. Required Name (required) Email (required) 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

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

Hi Matt, I think Name (required) is the best way of representing required fields, It is what I implemented for Griffith University. (see it in action: http://www.griffith.edu.au/cgi-bin/feedbackform.cgi ) Thinking further on the subject, if I was to redo the Styling I would probably have

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

> 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

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

On Feb 25, 2008, at 4:55 PM, Darren Lovelock wrote: I believe a more semantically correct method would be to use strong: Email: (Required) 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 tak

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

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 * First Name Just something I though

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

Darren Lovelock wrote: I believe a more semantically correct method would be to use strong: Email: (Required) 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

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

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 powe

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

What about *? 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

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

I believe a more semantically correct method would be to use strong: Email: (Required) 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:

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

Hi Thierry, 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 di

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

> 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

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 r

Re: [WSG] form problem

On 25 Feb 2008, at 22:46, Rob Unsworth wrote: <<-- changed from 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 bet

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

I agree with Jason, why not use both! There's something to be said about only using an * approach to indicate a mandatory field. In a recent project, even when explicitly saying on the screen that * means mandatory, the user still got it wrong. Providing a visual clue is a very good approach to th

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

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 av

Re: [WSG] form problem

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. <<-- changed from Comments: <<--Cols now 35 -- Regards,

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 > * First Name > > Just something I thought of :) Interesting discussion. You could also

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

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

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

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 fo

RE: [WSG] Site review

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 larg

Re: [WSG] re: generate data

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 librar

RE: [WSG] re: generate data

> 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

Re: [WSG] re: generate data

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

Re: [WSG] Site review

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

Re: [WSG] Site review

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

Re: [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

Re: [WSG] Site review

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 a

Re: [WSG] Site review

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://ju

[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 validat

Re: [WSG] form problem

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

Re: [WSG] re: generate data

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 di

Re: [WSG] Controling Windows DPI settings

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 :)

RE: [WSG] PDF Accessibility

Since version 7.05, Acrobat has had the ability to "Typewriter Enable" documents (look under Tools > Typewriter). In a Typewriter Enabled PDF the user CAN save a document in Adobe Reader with the data they entered. Formatting options are a bit basic but it can do the job. It's quite a useful functi