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