[WSG] Out of Office AutoReply: WSG Digest
Hi, I'm out of the office Wed 27th - Fri 29th February. I'll be back on Monday 3rd March. Contact Joi Champion or Amelia Brennan for whereis.com questions. Otherwise I will respond to your email upon my return. Karen Sensis. Australia's leading information resource. Making complex lives simpler by helping you find, buy and sell. www.sensis.com.au - www.yellow.com.au - www.whitepages.com.au - www.citysearch.com.au - www.about.sensis.com.au www.whereis.com.au - www.gostay.com.au - www.justlisted.com.au - www.tradingpost.com.au - www.linkme.com.au www.carshowroom.com.au - www.telstra.com.au - www.smallbusiness.sensis.com.au - www.universalpublishers.com.au Sensis cares for the environment - think before you print. This email and any attachments are intended only for the use of the recipient and may be confidential and/or legally privileged. Sensis Pty Ltd disclaims liability for any errors, omissions, viruses, loss and/or damage arising from using, opening or transmitting this email. If you are not the intended recipient you must not use, interfere with, disclose, copy or retain this email and you should notify the sender immediately by return email or by contacting Sensis Pty Ltd by telephone on [+61 3 8653 5000] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Unobtrusive JavaScript (was: generate data)
Hi, I've written a small set of helper functions that will allow you to unobtrusively add JavaScript to a web page. It's built on the back off the prototype library so you'll need that as well. See the details here: http://www.stillbreathing.co.uk/projects/performer/performer.html A couple of examples. 1) If you want to create a toggling element you can do this: pa href=# class=togger rel=toggleelementToggle the visibility of the toggleelement element/a/p div class=hider id=toggleelementThis element will be toggleable (is that a word?)/div The hider class on the toggleable element will hide the element only if JS is enabled, so if it's not the element will never be hidden. Of course you can add additional classes both to the link and the toggleable element, and you can set the href attribute of the link to whatever you want. 2) Loading remote content into an element (known as AJAX) pa href=# class=loader rel=targetelement rev=targetpage.phpLoad content/a/p p id=targetelementTarget element/p When the link with class loader is clicked the element with the id targetelement will be filled with the content from the targetpage.php page. If anyone needs any more information please get in touch. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Leventhal Sent: 25 February 2008 20:20 To: wsg@webstandardsgroup.org Subject: 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] *** This message has been scanned for malware by SurfControl plc. www.surfcontrol.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Unobtrusive JavaScript (was: generate data)
Hi, Although I'm a jQuery man myself, it's good to see someone actively encouraging the use of unobtrusive javascript although I would make one or two tweaks. Wouldn't it be better to add your class hooks to the p rather than to an a as at present, if the user had javascript disabled then they would have a link saying toggle that would take them to the top of the page if clicked. Even better would be to insert the a using javascript so that if you have javascript disabled you don't even get the option to toggle visibility - the item is just there. Just a thought! Cheers, Ben -- e: [EMAIL PROTECTED] w: http://www.bendodson.com/ On 26/02/2008, Chris Taylor [EMAIL PROTECTED] wrote: Hi, I've written a small set of helper functions that will allow you to unobtrusively add JavaScript to a web page. It's built on the back off the prototype library so you'll need that as well. See the details here: http://www.stillbreathing.co.uk/projects/performer/performer.html A couple of examples. 1) If you want to create a toggling element you can do this: pa href=# class=togger rel=toggleelementToggle the visibility of the toggleelement element/a/p div class=hider id=toggleelementThis element will be toggleable (is that a word?)/div The hider class on the toggleable element will hide the element only if JS is enabled, so if it's not the element will never be hidden. Of course you can add additional classes both to the link and the toggleable element, and you can set the href attribute of the link to whatever you want. 2) Loading remote content into an element (known as AJAX) pa href=# class=loader rel=targetelement rev=targetpage.phpLoad content/a/p p id=targetelementTarget element/p When the link with class loader is clicked the element with the id targetelement will be filled with the content from the targetpage.php page. If anyone needs any more information please get in touch. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Leventhal Sent: 25 February 2008 20:20 To: wsg@webstandardsgroup.org Subject: 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] *** This message has been scanned for malware by SurfControl plc. www.surfcontrol.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
Hi Matt, 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, [...] I agree. [...] which I imagine can be tedious using a screen reader. Is this the case? Can be a horror show. My understanding is that client side (using JavaScript alerts) is actually pretty accessible. For server side, my v2 [1] form script bookmarks the success/error message (#results) bringing the user directly to the message. The message tells them what's wrong, they go back and fix the issue. Going back doesn't take them directly to the culprit input so they have to navigate to it. This is the version (modified a bit more) I'm using (have to for now) on the site I had mentioned. The error management was noted, favorably. Even better, dare I say the best way, is how I manage errors on my v3 [2] form. The user is directed to the error, on the same page, and links are provided taking the user directly to the culprit input/s. All errors now do this, and some take it a step further. For example, if the anti-spam question is wrong the script returns the error, a link, and also gives the user the right answer (my attempt to better satisfy the needs of those with cognitive disabilities). Also, there is a honeypot input (to lure 'bots). Users are told to keep it empty in the label, but if they mistakenly fill it in they are notified of the error, the input is cleared for them, and they are given a link to the submit and asked to try again. Balancing accessibility and the security is delicate. It would be great if you could keep us posted about any feedback you get in March when the site goes live. Will do. Nothing's perfect so I'm sure I'll get useful feedback from people who see it. Hope so anyway. 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 That'd be great, Matt. Thanks. Mike Live Demo Forms: [1] http://green-beast.com/gbcf/gbcf_form.php [2] http://green-beast.com/gbcf-v3/test-form.php *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Web Browser Testing and the Practicallity of Testing other OS's
Hi WSG, I'm testing a custom application to see if it works in different OS's and Web Browsers. My question is there any practical reason to test different OS when you can download them on your current OS. eg. W2K Internet Explorer 5.5 vs WXP Internet Explorer 5.5 I have multiple IE but is there really any reason to use a different OS? Is the web browser going to be any different? Anyone with web browser testing experience have any advise? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Unobtrusive JavaScript (was: generate data)
Good ideas Ben, thanks. I did think about that but went for the option which means the least amount of work for the developer. I don't pretend that Performer is suitable for really advanced stuff, just the basics. The reason I hook the events into the a element is because it gives the developer the opportunity to use the link as a link in the even of a non-JS user. For example: pa href=index.php?toggle= toggleelement class=togger rel=toggleelementToggle the visibility of the toggleelement element/a/p The querystring parameters in the href of this link could tell some server-side code to apply a class to the element. It's a simple example, but I'm sure you can see how this could be used to provide both a standard and enhanced interface to the user. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Dodson Sent: 26 February 2008 11:30 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Unobtrusive JavaScript (was: generate data) Hi, Although I'm a jQuery man myself, it's good to see someone actively encouraging the use of unobtrusive javascript although I would make one or two tweaks. Wouldn't it be better to add your class hooks to the p rather than to an a as at present, if the user had javascript disabled then they would have a link saying toggle that would take them to the top of the page if clicked. Even better would be to insert the a using javascript so that if you have javascript disabled you don't even get the option to toggle visibility - the item is just there. Just a thought! Cheers, Ben -- e: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] w: http://www.bendodson.com/ On 26/02/2008, Chris Taylor [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Hi, I've written a small set of helper functions that will allow you to unobtrusively add JavaScript to a web page. It's built on the back off the prototype library so you'll need that as well. See the details here: http://www.stillbreathing.co.uk/projects/performer/performer.html A couple of examples. 1) If you want to create a toggling element you can do this: pa href=# class=togger rel=toggleelementToggle the visibility of the toggleelement element/a/p div class=hider id=toggleelementThis element will be toggleable (is that a word?)/div The hider class on the toggleable element will hide the element only if JS is enabled, so if it's not the element will never be hidden. Of course you can add additional classes both to the link and the toggleable element, and you can set the href attribute of the link to whatever you want. 2) Loading remote content into an element (known as AJAX) pa href=# class=loader rel=targetelement rev=targetpage.phpLoad content/a/p p id=targetelementTarget element/p When the link with class loader is clicked the element with the id targetelement will be filled with the content from the targetpage.php page. If anyone needs any more information please get in touch. Chris -Original Message- From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Ray Leventhal Sent: 25 February 2008 20:20 To: wsg@webstandardsgroup.orgmailto:wsg@webstandardsgroup.org Subject: 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.comhttp://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]mailto:[EMAIL PROTECTED] *** This message has been scanned for malware by SurfControl plc. www.surfcontrol.comhttp://www.surfcontrol.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL
Re: [WSG] strong element being more semantical and accessible for required field
don't know if this has been pointed out yet, but as far as screen readers like JAWS and Window Eyes are concerned the strong element does not convey any meaning. It is not recognised by them. They do not change the way text within strong elements are announced, but neither do they do it for em or b or i etc. JAWS does have a speech and sound scheme that includes modified announements of italicised or bolded text (amogst other things), this is not a default scheme, though and is provided for tasks such as proofreading. but this facility is based on how the text is rendered on screen, not on how it is marked up. bottom line is that for users these screen readers using strong as an indication of a required field won't be of any help. On 25/02/2008, tee [EMAIL PROTECTED] 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] *** -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Web Browser Testing and the Practicality of Testing other OSs
This kind of testing is our core business, and I have to say that these days there is very little difference when running a particular browser version on different Windows versions. One difference that comes to mind is that Windows 2000 has native 56-bit encryption, and this is not increased even when Internet Explorer 6 is installed. We frequently encounter issues (i.e. the site does not load at all) when the SSL server is not configured correctly for this encryption level even though it may work with 40-bit and 128-bit browsers. XP was 128-bit from the start. There is a High Encryption Pack for Win 2000 but I have no idea how many users have it. SP2, SP3 and SP4 for Win 2000 upgraded the encryption to 128-bit although SP1 did not. Win 2000 did not come with Flash, whereas XP came with Flash version 6r79, so the testing of the Flash detection routine would be slightly different. There were also differences in the Java Virtual Machine in Win 2000 and XP (XP SP1a and onwards don't even have a JVM) but I doubt that that is relevant in your case. Firefox behaves the same on all Windows versions but there are slight differences (usually with fonts) on Mac and Linux. These can cause knock-on effects with the layout, although they should not if the site has been designed to accommodate increases in text size. I absolutely would not ever use standalone versions of Internet Explorer for testing. I know people do, and for trivial applications you may consider that to be adequate. However, the behaviour is not the same, and the differences are not quantified anywhere that I am aware of, so you do not know if they are relevant to your application. I would be happy to take a look at your application and see if there are any areas where the OS would make a difference. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew WC Brown Sent: 26 February 2008 14:29 To: wsg@webstandardsgroup.org Subject: [WSG] Web Browser Testing and the Practicallity of Testing other OS's Hi WSG, I'm testing a custom application to see if it works in different OS's and Web Browsers. My question is there any practical reason to test different OS when you can download them on your current OS. eg. W2K Internet Explorer 5.5 vs WXP Internet Explorer 5.5 I have multiple IE but is there really any reason to use a different OS? Is the web browser going to be any different? Anyone with web browser testing experience have any advise? *** 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
Something quick I just thought of was that you could use some small icon to indicate required fields, and specify the alt for that to say required. That way, sighted users don't have to look at the word required repeated 50 times, while unsighted users will be able to hear that the field is required. Just a thought. Steven Faulkner wrote: don't know if this has been pointed out yet, but as far as screen readers like JAWS and Window Eyes are concerned the strong element does not convey any meaning. It is not recognised by them. They do not change the way text within strong elements are announced, but neither do they do it for em or b or i etc. JAWS does have a speech and sound scheme that includes modified announements of italicised or bolded text (amogst other things), this is not a default scheme, though and is provided for tasks such as proofreading. but this facility is based on how the text is rendered on screen, not on how it is marked up. bottom line is that for users these screen readers using strong as an indication of a required field won't be of any help. On 25/02/2008, *tee* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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] mailto:[EMAIL PROTECTED] *** -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com http://www.paciellogroup.com | www.wat-c.org http://www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Christian Snodgrass Azure Ronin Web Design http://www.arwebdesign.net/ http://www.arwebdesign.net Phone: 859.816.7955 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Special site check invitation (for one)
Hello all, I am looking for a volunteer to check out a web site for me. I need another set of eyes. This volunteer needs the following: 1) Access to an extra wide viewport (beyond 1024). 2) A solid knowledge of CSS so if a bug is found, together we might be able to find a fix (you will be properly credited if it comes to this). 3) Different browsers on which to look (FF IE6,7, OP, Safari) on Windows. Mac, too, would be beneficial but not necessary. 4) A static IP so you can be added to the approved viewer's array. If you meet the requirements and you're interested in helping, please contact me off-list. At which point I will announce here a volunteer was found. Thanks. Respectfully, Mike Cherim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Web Browser Testing and the Practicallity of Testing other OS's
It might be worth testing on different platforms. Firefox 2.0 on Windows, OSX and Linux. I belive there some times are some quirks that creeps up. All though rare. - Original Message - From: Andrew WC Brown To: wsg@webstandardsgroup.org Sent: Tuesday, February 26, 2008 3:28 PM Subject: [WSG] Web Browser Testing and the Practicallity of Testing other OS's Hi WSG, I'm testing a custom application to see if it works in different OS's and Web Browsers. My question is there any practical reason to test different OS when you can download them on your current OS. eg. W2K Internet Explorer 5.5 vs WXP Internet Explorer 5.5 I have multiple IE but is there really any reason to use a different OS? Is the web browser going to be any different? Anyone with web browser testing experience have any advise? *** 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] Special site check invitation (COMPLETE)
Hello all, Thank you to all who volunteered. I owe you one :) I did actually extend the invitation to three people -- more the merrier, right? Cheers. Mike *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] generated source
Does anyone have a preferred way to view and validate generated source code? By generated source I mean after Ajax, JavaScript, and so on have done their magic. I'm asking because I'm working on a web application for browsing network devices (close to 9000 routers, switches, WAPs, etc.) that relies on JavaScript (some homemade JS, jQuery, Ajax and JSON) to build virtually all the XHTML. Yet, when I view source via the debug inspect element feature in the latest release of Safari or using Pederick's web developer Firefox add-on, closed tags become unclosed. For example: meta http-equiv=Content-Type content=text/html; charset=UTF-8 / Becomes: meta http-equiv=Content-Type content=text/html; charset=UTF-8 Yet viewing generated source in Firebug, that same meta tag remains closed. Firebug, however, doesn't have (or I haven't noticed?) a way to copy and paste source code for direct input validation to the W3C validator. This, then, is the ultimate goal: to get the generated source, copy it and paste it into a validator. I validated with static mockups prior to de-building the XHTML and giving it over to JavaScript, but I want to validate now to make sure I'm staying on track. Have others run into this problem? Thanks in advance, Jody -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] generated source
Hi Jody, I recall having a similar problem. The issue came down (from memory) to the doctype I was using. I was closing elements in xhtml style, while the doctype I was using was html. Firefox was happily removing the extraneous closing elements in the rendered source to fit the doctype. :) Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Special site check invitation (COMPLETE)
Also a thank you for informing everyone that it is completed. This tends not to happen a lot and people (like myself) see the message a few days later and find that the site is taken down. thanks, William Mike at Green-Beast.com wrote: Hello all, Thank you to all who volunteered. I owe you one :) I did actually extend the invitation to three people -- more the merrier, right? Cheers. 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] ***
Re: [WSG] generated source
Thanks, Paul, for the suggestion. Doctype, I don't think, is the issue. The doctype is set in the static XHTML that the Ajax builds on as XHTML strict. However, most generated source views remove the doctype, a phenomenon I asked about here: http://ask.metafilter.com/84314/Where-does-the-DTD-go . The W3C validator lets you re-declare a doctype if one is missing, http://validator.w3.org/#validate_by_input+with_options , but even using that option, many of my tags are still already unclosed from the generated source view. -jody On Feb 26, 2008, at 11:37 AM, Paul Bennett wrote: Hi Jody, I recall having a similar problem. The issue came down (from memory) to the doctype I was using. I was closing elements in xhtml style, while the doctype I was using was html. Firefox was happily removing the extraneous closing elements in the rendered source to fit the doctype. :) Paul *** 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] generated source
There are a few plugins for firefox that does validation for you. Can't remember the names of them offhand though. Sorry. On Wed, Feb 27, 2008 at 4:44 AM, jody tate [EMAIL PROTECTED] wrote: Does anyone have a preferred way to view and validate generated source code? By generated source I mean after Ajax, JavaScript, and so on have done their magic. I'm asking because I'm working on a web application for browsing network devices (close to 9000 routers, switches, WAPs, etc.) that relies on JavaScript (some homemade JS, jQuery, Ajax and JSON) to build virtually all the XHTML. Yet, when I view source via the debug inspect element feature in the latest release of Safari or using Pederick's web developer Firefox add-on, closed tags become unclosed. For example: meta http-equiv=Content-Type content=text/html; charset=UTF-8 / Becomes: meta http-equiv=Content-Type content=text/html; charset=UTF-8 Yet viewing generated source in Firebug, that same meta tag remains closed. Firebug, however, doesn't have (or I haven't noticed?) a way to copy and paste source code for direct input validation to the W3C validator. This, then, is the ultimate goal: to get the generated source, copy it and paste it into a validator. I validated with static mockups prior to de-building the XHTML and giving it over to JavaScript, but I want to validate now to make sure I'm staying on track. Have others run into this problem? Thanks in advance, Jody -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- - http://myfitness.ning.com A community of people that care about their health and fitness Free fitness videos, recipes, blogs, photos etc. -- *** 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 Steven, On Feb 26, 2008, at 6:49 AM, Steven Faulkner wrote: don't know if this has been pointed out yet, but as far as screen readers like JAWS and Window Eyes are concerned the strong element does not convey any meaning. It is not recognised by them. bottom line is that for users these screen readers using strong as an indication of a required field won't be of any help. Thanks for the great info. Exactly what I am after. I like the way Mike grouped the required elements, will borrow the idea for the next form. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] WCAG Samurai released.
Members of this list should be interested that the WCAG Samurai errata for Web Content Accessibility Guidelines 1.0 has been released. http://wcagsamurai.org/ For those not familiar with the Samurai errata, it is alternative to the FUBARed WCAG 2.0 For more information on what happened to WCAG 2.0, please read http://alistapart.com/articles/tohellwithwcag2 Kind Regards, Kane Tapping Web Standards Developer Web and Content Management Services Griffith University. 4111. Australia. [EMAIL PROTECTED] Phone: +61 (0)7 3735 7630 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] generated source
On Tue, 26 Feb 2008 10:44:13 -0800, jody tate wrote: Does anyone have a preferred way to view and validate generated source code? By generated source I mean after Ajax, JavaScript, and so on have done their magic. [...] Yet viewing generated source in Firebug, that same meta tag remains closed. Firebug, however, doesn't have (or I haven't noticed?) a way to copy and paste source code for direct input validation to the W3C validator. This, then, is the ultimate goal: to get the generated source, copy it and paste it into a validator. I validated with static mockups prior to de-building the XHTML and giving it over to JavaScript, but I want to validate now to make sure I'm staying on track. Have others run into this problem? Yes. I have come across it, although for me it is not a problem. This behavior seems logical to me. After all, what displays is the browser's interpretation of the document, which is likely HTML. Unless you are doing something server-side, you are likely sending the documents to the browser with an HTML MIME type, as opposed to XHTML, which requires special handling. One suggestion I have to get Firefox to treat the page as XHTML is to rename your document with dot-xhtml (.xhtml) extension instead of the dot-htm or dot-html. This works from the hard drive, and quite a few hosts are set up to send the correct MIME type as well. Not all are though - you need to check with your host. You may have problems viewing this in Internet Explorer, so don't use it as a permanent web page - just use it for your purpose of validating generated code. I hope this suggestion helps. [Aside] I help out at a computer lab where web design is taught. One misconception I see over and over is that putting things like an XHTML DOCYPE or declaring UTF-8 encoding in a META element somehow alters the document itself. Saying it is so does not make it so, despite what certain politicians would have us believe. Cordially, David -- *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Unobtrusive JavaScript (was: generate data)
Hi Chris Thought I'd let you know - I looked at your web page and the first two examples, when I clicked on the link, didn't work for me at all! No extra paragraph appearing (or disappearing!) and no time change. I'm on a Mac using Firefox 2.0.0.12 ... It sounds good - I'd like to access a version that works ... :) Cheers susie On 26/2/08 8:16 PM, Chris Taylor [EMAIL PROTECTED] wrote: Hi, I've written a small set of helper functions that will allow you to unobtrusively add JavaScript to a web page. It's built on the back off the prototype library so you'll need that as well. See the details here: http://www.stillbreathing.co.uk/projects/performer/performer.html A couple of examples. 1) If you want to create a toggling element you can do this: pa href=# class=togger rel=toggleelementToggle the visibility of the toggleelement element/a/p div class=hider id=toggleelementThis element will be toggleable (is that a word?)/div The hider class on the toggleable element will hide the element only if JS is enabled, so if it's not the element will never be hidden. Of course you can add additional classes both to the link and the toggleable element, and you can set the href attribute of the link to whatever you want. 2) Loading remote content into an element (known as AJAX) pa href=# class=loader rel=targetelement rev=targetpage.phpLoad content/a/p p id=targetelementTarget element/p When the link with class loader is clicked the element with the id targetelement will be filled with the content from the targetpage.php page. If anyone needs any more information please get in touch. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Leventhal Sent: 25 February 2008 20:20 To: wsg@webstandardsgroup.org Subject: 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] *** This message has been scanned for malware by SurfControl plc. www.surfcontrol.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] generated source
Does anyone have a preferred way to view and validate generated source code? By generated source I mean after Ajax, JavaScript, and so on have done their magic. I like the view generated source in the Web Developer Firefox plugin, Firebug is very handy too btw does anyone know how to get Firefox 2 plugins to work in Firefox 3 beta? for some reason I can't seem to use both at the same time on the same machine... (I hope Firefox isn't going down the IE route of only letting you use one version at a time!) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Site review - alachua co library
On 2008/02/25 10:31 (GMT-0500) Andrew Maben apparently typed: 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 ... Of course accessibility is important, and this is where your insights and criticisms can be especially helpful. http://www.andrewmaben.net [EMAIL PROTECTED] It's quite a bit better than its close neighbor http://www.ufl.edu/ and better in some ways than the original, but worse in others. I really don't like the artificial width constraint that the original lacks. Width should only be constrained to less than 100% of the window width to the extent wider would produce too long line lengths for comfortable reading. There's no chance of that on the new page, while quite a bit of it looks over-constrained without enlarging the text, and most of it does with text enlargement. The other problem is the same as most of the web, too much too small text. Nearly right smack dab in the middle of above the fold content is what looks like primary content, yet it's shrunken to the size of UI text, smaller than the menu text, creating the inference that it's less important than other content. Most of the text-in-image content is illegible or nearly so on median or higher resolution displays. Those using the most expensive laptops will not be pleased at the mousetype effect of africanamerican_history_onli.gif hot_topics/webfeat.jpg or the last line of acld_Logo.gif. Foreground images can and in many cases should be scaled up to match surrounding text, and these are some of those cases. At least the original is blatantly up front about enabling large enough to read text. Here's a screenshot of a typical moderately high resolution environment: http://mrmazda.no-ip.com/SS/SC/sc-alaclib1.jpg and the setup source: http://mrmazda.no-ip.com/tmp/sc-alaclib1.html The main branch used to be about a 10 minute walk from where I lived. If I still lived just a bit closer I might be inclined to ride over to the main branch, find the manager, and complain about waste of money on a redesign that doesn't amount to much readily apparent improvement. Maybe its only real goal is to get people in to read printed material that doesn't suffer from the web's normally too small text, but if that's it, the address and phone number should be at least as big as it is in the phone book. :-p -- For God so loved the world that he gave his one and only Son, that whoever believes in him shall not perish but have eternal life. John 3:16 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Site review - alachua co library
Hi Felix, Here's a screenshot of a typical moderately high resolution environment: http://mrmazda.no-ip.com/SS/SC/sc-alaclib1.jpg and the setup source: http://mrmazda.no-ip.com/tmp/sc-alaclib1.html Just a thought, but a moderately high resolution environment to me is a setup of over 3mpx. For instance, dual 20 TFTs, dual 19 CRT or single 30 etc. A high resolution environment for me is about 7.5mpx. While I'm aware that your mileage may vary, a 1680 x 1200 pixel screen size is certainly not a standard one! Thus I'm really curious about your definition of a standard one! The Standard Panels Working Group (SPWG) isn't the fastest moving of organisations, admittedly, but you'll find that they're usually ratifying 16:10 aspect ratios as standard - something to consider when designing sites. Additionally, those of us with extremely large working areas should usually have a 17 TFT or lower to test on for 'the great unpixeled'. kind regards, John Hancock Identity [EMAIL PROTECTED] t: +61 2 8012 0274 f: +61 2 9799 6135 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
