RE: [WSG] Keeping state of behaviors
On Behalf Of Breton Slivka On 6/8/07, Thierry Koblentz [EMAIL PROTECTED] wrote: I put this together, but I'm not sure it could be useful for anything... May be it could be used with Ajax stuff, when the back button is a concern. http://www.tjkdesign.com/articles/keeping_state/keeping_track.html This is quite useful to me. Though I don't quite understand how it works. Is the iframe important to the functioning? Is there a way to do the same thing, but make the state bookmarkable? I wanted to get some feedback before writing something about this solution as I'm not sure what would be the best way to use it. It is in fact the iframe that does all the work, I'm using its URI to hold/keep track of the values. I started with a regular frameset hoping that it would be possible to bookmark the state in IE (as this browser can bookmark frameset state), but when I saw that it didn't work I dropped the frameset for an iFrame. --- Regards, Thierry | www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
What is your opinion on the errata ? It's an excellent read. Certainly therapeutic, particularly with Joe Clarke's wonderfully acerbic wit showing in places. I think what it truly does is define the Best Practice accessibility which has evolved under WCAG 1.0, which made some assumptions which were proven incorrect over time. Realistically most developers stopped shooting for perfect compliance, since some of the rules conflict with feedback from real live users. Tabindex is a perfect example - if the logical flow is so busted that you have to override it, the page should be recreated in a clearer form. Entering default text into form inputs is another rule which the experts tell me no longer applies. Samurai corrects a lot of those problems and does so in language which is usually pretty clear. The only downside is that there are still plenty of points which could be misinterpreted or quoted out of context to support spurious practices. It's readable though - calls a spade a spade. cheers, Ben -- --- http://www.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
On Fri, 8 Jun 2007 15:22:36 +1000, Kane Tapping wrote: I have been reading with interest the WCAG Samurai Errata ( http://wcagsamurai.org/errata/intro.html ) and am suprised to have not found it discussed on WSG as of yet. Thank you! I missed this announcement, somehow. What a refreshing read! :) Points - no noscript? I still use it to add a submit button to dropdowns which are otherwise javascript driven - I thought I was doing a good thing! (Wah! :( ) Hmm.. its in the introduction, but not in the document. Thats not right, surely? - Guideline 10 Do not add non-link, printable characters (surrounded by spaces or not) between adjacent links unless the semantics of the document naturally would include such characters. Am I right in interpeting this as that we *don't* need to make sure there are extra characters between links! Wow! Cool! :) :reads more: warmly, Lea -- Lea de Groot Elysian Systems Brisbane, Australia *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
On 08/06/07, Frank Palinkas [EMAIL PROTECTED] wrote: /* Guideline 9.4: Do not attempt to create your own tab order. That is a job for a browser and adaptive technology. */ When and where needed (in web forms for instance), I create a tabindex order starting with the number 11 and proceed from there. This usually bypasses the generic built-in browser tab order. So what would happen on a page with 15 links above the form? Presumably a keyboard user would tab through the first 10, then just down to the form, through that, and then back to the last 5, then move onto any links after the form. Not exactly expected behaviour. /* Guideline 9.5: Don't provide your own keyboard shortcuts. That is a job for a browser or adaptive technology. */ I provide keyboard shortcuts for global navigation situated on each web page. I cross-browser test to make sure each character I'm using for the Alt + key shortcut doesn't interfere with generic browser shortcuts. I think it's been shown that just about all keys interfere with someone's shortcuts, whether it's a browser, screenreader, foreign characters, or whatever. Matthew. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
On 08/06/07, Lea de Groot [EMAIL PROTECTED] wrote: - no noscript? I still use it to add a submit button to dropdowns which are otherwise javascript driven - I thought I was doing a good thing! Auto-submitting dropdowns are not usable by keyboard users. Matthew. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
I like the way that the footer links rollover to black text on dark blue background - very accessible... ;) Matthew. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] WCAG Samurai Errata
Hi Matthew, Thanks for your comments. /* So what would happen on a page with 15 links above the form? Presumably a keyboard user would tab through the first 10, then just down to the form, through that, and then back to the last 5, then move onto any links after the form. Not exactly expected behaviour. */ I always add a Skip Navigation button directly after the h1 topic enabling a user to bypass both global and internal page links. This moves the focus to the first subtopic. I use 11 as a starting guide, not as a rule. /* I think it's been shown that just about all keys interfere with someone's shortcuts, whether it's a browser, screenreader, foreign characters, or whatever. */ Interesting. Please tell me where this info is shown? I'd like to know more. Kind regards, Frank From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Pennell Sent: Friday, 08 June, 2007 8:26 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] WCAG Samurai Errata On 08/06/07, Frank Palinkas [EMAIL PROTECTED] wrote: /* Guideline 9.4: Do not attempt to create your own tab order. That is a job for a browser and adaptive technology. */ When and where needed (in web forms for instance), I create a tabindex order starting with the number 11 and proceed from there. This usually bypasses the generic built-in browser tab order. So what would happen on a page with 15 links above the form? Presumably a keyboard user would tab through the first 10, then just down to the form, through that, and then back to the last 5, then move onto any links after the form. Not exactly expected behaviour. /* Guideline 9.5: Don't provide your own keyboard shortcuts. That is a job for a browser or adaptive technology. */ I provide keyboard shortcuts for global navigation situated on each web page. I cross-browser test to make sure each character I'm using for the Alt + key shortcut doesn't interfere with generic browser shortcuts. I think it's been shown that just about all keys interfere with someone's shortcuts, whether it's a browser, screenreader, foreign characters, or whatever. Matthew. *** 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] WCAG Samurai Errata
Hi , - no noscript? I still use it to add a submit button to dropdowns which are otherwise javascript driven - I thought I was doing a good thing! (Wah! :( ) Hmm.. its in the introduction, but not in the document. Thats not right, surely? I took this one to mean that you should be writing your form in a accessible and non-js way first then use JS to HIJAX ( http://ajaxian.com/archives/hijax-graceful-degration) that version to provide enhanced useability.This way you get a perfectly useable form without JS and enhanced usability when it is enabled. Kind Regards, Kane Tapping Web Standards Developer Web and Content Management Services Griffith University. 4111. Australia. [EMAIL PROTECTED] Phone: +61 (0)7 3735 7630 [EMAIL PROTECTED] wrote on 08/06/2007 04:19:08 PM: On Fri, 8 Jun 2007 15:22:36 +1000, Kane Tapping wrote: I have been reading with interest the WCAG Samurai Errata ( http://wcagsamurai.org/errata/intro.html ) and am suprised to have not found it discussed on WSG as of yet. Thank you! I missed this announcement, somehow. What a refreshing read! :) Points - no noscript? I still use it to add a submit button to dropdowns which are otherwise javascript driven - I thought I was doing a good thing! (Wah! :( ) Hmm.. its in the introduction, but not in the document. Thats not right, surely? - Guideline 10 Do not add non-link, printable characters (surrounded by spaces or not) between adjacent links unless the semantics of the document naturally would include such characters. Am I right in interpeting this as that we *don't* need to make sure there are extra characters between links! Wow! Cool! :) :reads more: warmly, Lea -- Lea de Groot Elysian Systems Brisbane, Australia *** 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] WCAG Samurai Errata
On Fri, 8 Jun 2007 07:27:46 +0100, Matthew Pennell wrote: Auto-submitting dropdowns are not usable by keyboard users. More information, please? :) warmly, Lea -- Lea de Groot Elysian Systems Brisbane, Australia *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
On Fri, 8 Jun 2007 16:49:00 +1000, Kane Tapping wrote: I took this one to mean that you should be writing your form in a accessible and non-js way first then use JS to HIJAX ( http://ajaxian.com/archives/hijax-graceful-degration) that version to provide enhanced useability.This way you get a perfectly useable form without JS and enhanced usability when it is enabled. I have considered that, and there are very, very few places where I would use a noscript element - the 'select dropdown' is probably the only *common* implementation I do. The only problem with the 'make it plain, then pretty it with JS' approach is the Redraw Problem. The first thing to bear in mind is that for the majority of applications more than 95% of your visitors will be using a plain vanilla graphical browser. While a web page/app must be accessiible, it must also service your majority audience *perfectly*. Having elements pop in and out on a slow connection is very confusing for Joe Public, and if its a page or site that will take their money its important Not to make them feel in anyway insecure on what is happening. Because of this, I've made a specific decision that, rather than having a: select + button, then use JS to remove the button and add an onclick, I have: select + noscripted-button, and use js to add an onclick (actually, I think its an onchange - I'd have to go look). This gives an almost identical experience to non-js browsers and a perfect experience to Joe Public's vanilla browser, and avoids elements popping in and out on the screen. If its below the fold it doesn't matter so much If the element is very visible at the top of the page then its important. It would probably be worthwhile to consider browsers that do js, but don't support onchange but I haven't looked into it - its a pretty old element. IMHO warmly, Lea -- Lea de Groot Elysian Systems Brisbane, Australia *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
This is an interesting one: If images must be used for list bullets, do so only using CSS, as with ul { list-style: url(arrow.gif) disc } Like a lot of people, I use CSS background-image to place a graphic at the top left of LI items, with a bit of left padding so the text makes space. What is the justification for this new 'rule' - how does background-image negatively affect accessibility in a way that graphical list-style doesn't? Matthew. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] WCAG Samurai Errata
Matthew Pennell wrote: I think it's been shown that just about all keys interfere with someone's shortcuts, whether it's a browser, screenreader, foreign characters, or whatever. Frank Palinkas wrote: Interesting. Please tell me where this info is shown? I'd like to know more. Some Info: http://www.wats.ca/show.php?contentid=32 http://www.wats.ca/show.php?contentid=43 http://juicystudio.com/article/firefox2-accesskeys.php Regards Jason *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
On 08/06/07, Lea de Groot [EMAIL PROTECTED] wrote: On Fri, 8 Jun 2007 07:27:46 +0100, Matthew Pennell wrote: Auto-submitting dropdowns are not usable by keyboard users. More information, please? :) Auto-submit dropdowns mostly work by triggering the onchange event of the SELECT element. This is fired when you select a different OPTION using a mouse - however, if you are using a keyboard, it is fired when you press the down arrow to move through the list. You therefore can't select anything but the first OPTION, as it triggers the onchange event and submits the form. Matthew. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Use of PDFs - Accessibility issues
Hi, Have you tried RiverDocs: http://www.riverdocs.com/index.htm. You can sign up for a free evaluation licence for 14 days (no restrictions): http://www.riverdocs.com/product/download/index.html. The price is £399. If you are a member of GAWDS the cost is £299 until 22 June. Regards, Elaine Web Designer http://www.webdandy.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Palinkas Sent: 08 June 2007 06:19 To: wsg@webstandardsgroup.org Subject: RE: [WSG] Use of PDFs - Accessibility issues Hi Michael, Not sure if this will help you, but on occasion I've been presented with .pdf files to convert to (x)html for web-based tech docs. I do this manually by creating templates in the Visual Studio 2005 markup source code editors, and then copy and paste the content from the .pdf's. This way I have complete control over the structure, presentation and behavior of the resulting web doc. This is ok if the .pdf's haven't been secured by a user name and password. If they have, then I'm outta luck as the copy/paste routine won't work. Personally, I wouldn't trust any .pdf to .html conversion app. If they exist, I feel it would create more work than what I already have to do in this scenario. Kind regards, Frank M. Palinkas Microsoft M.V.P. - Windows Help W3C HTML Working Group (H.T.M.L.W.G.) - Invited Expert M.C.P., M.C.T., M.C.S.E., M.C.D.B.A., A+ Senior Technical Communicator Web Standards Accessibility Designer website: http://frank.helpware.net email: [EMAIL PROTECTED] | [EMAIL PROTECTED] Member: Society for Technical Communications (S.T.C.) Guild of Accessible Web Designers (G.A.W.D.S.) Web Standards Group (W.S.G.) Supergroup Trading Ltd. Sandhurst, Gauteng, South Africa website: http://www.supergroup.co.za Work: +27 011 523 4931 Home: +27 011 455 5287 Fax: +27 011 455 3112 Mobile: +27 074 109 1908 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael MD Sent: Friday, 08 June, 2007 6:41 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Use of PDFs - Accessibility issues Here is the thread that discussed making PDFs accessible: http://www.mail-archive.com/wsg@webstandardsgroup.org/msg28067.html The effort involved in creating the PDFs in an accessible format will be significant. Handheld users frequently avoid opening PDFs since they are often a large file size - bandwidth and cost being the limiting factors here. how many mobile phone can read pdf? .. I suspect not many yet ... (I have yet to see one which can) btw does anyone know of anything that can export html (even if it is crap html) from a pdf ? (apart from Acrobat Pro itself - I can't justify spending that sort of money for just the occasional attempt to extract useful content from that occasasional pdf sent by clueless media publicists which would otherwise just be deleted) *** 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] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] WCAG Samurai Errata
Thanks Jason, That's what I'm looking for. Also, I think Gez Lemon's comment about letting a user set their own access keys makes a lot of sense to me. Kind regards, Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Turnbull Sent: Friday, 08 June, 2007 9:53 AM To: wsg@webstandardsgroup.org Subject: RE: [WSG] WCAG Samurai Errata Matthew Pennell wrote: I think it's been shown that just about all keys interfere with someone's shortcuts, whether it's a browser, screenreader, foreign characters, or whatever. Frank Palinkas wrote: Interesting. Please tell me where this info is shown? I'd like to know more. Some Info: http://www.wats.ca/show.php?contentid=32 http://www.wats.ca/show.php?contentid=43 http://juicystudio.com/article/firefox2-accesskeys.php Regards Jason *** 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] WCAG Samurai Errata
Another interesting one, under Guideline 12 (although it actually relates to WCAG 13.8): Do not place distinguishing information at the beginning of headings, paragraphs, lists, etc. unless document semantics warrant it. I'd always interpreted that guideline as being a nod to both usability and cognitive disability, with the added bonus that it means screenreader users don't have to listen to the entire sentence before being in a position to decide if it is relevant to them - for example: Bad: Read more information and download supporting material on California Forest Fires Good: Californian Forest Fires - more information and support material So why is this bad, and why does the Samurai's new 'rule' seem to be recommending that we actively avoid putting distinguishing information at the start of sentences? Doesn't make sense to me. Matthew. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Print style sheets
Generally speaking, my advice would be to use print styles as part of the main stylesheet setup (possibly but not necessarily a separate CSS file) By tying your print-friendly styles to a script of any kind, you are forcing the user to find that link and be able to use it, in order to gain the benefit. It does depend a lot on what the site looks like to begin with, but try turning the question around, and asking yourself what the user would gain by being able to print the site exactly as it looks on the screen? Regards, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lucien Stals Sent: Friday, June 08, 2007 6:18 AM To: WSG Subject: [WSG] Print style sheets Hi all, I'd written a print style sheet for a site I'd done ( http://www.swin.edu.au/ads/ltshowcase/inspire/presentations.html ), but the feedback I got was that nobody knew it was there (unless they printed the page). So I hit google for some suggestions on how best to do this. This has lead to more confusion. One site I read suggested that print style sheets can confuse users when what comes out of the printer differs significantly from what they saw on the page. This is true in my case where I hide the navigation and some background images. I also change the font and justification to better suit print. So do people here think it's a good idea to have a print style sheet that differs from the screen style sheet? In the end, I used some javascript to allow users to switch between two style sheets on the screen. One is designed for the screen, the other designed for print. This way, if they print the page, they get what they see. What do people think about this approach. (If you are unclear from my description about how this works, just visit the page and toggle the print friendly view link near the top of the page). My approach has caused me a further problem: Because I used a link to trigger the script, clicks get added to the browsers history, when technically the user hasn't left the page. Any suggestions for how to get around this? Should I have used a select list? Regards, Lucien. -- Lucien Stals Multimedia/Web Developer Academic Development and Support Swinburne University of Technology PO Box 218 Hawthorn, 3122, Australia email: [EMAIL PROTECTED] telephone: +61 3 9214 4474 office: AD223 Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. *** 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] WCAG Samurai Errata
Hi, I think the as with here means as example. The point is the use of CSS to avoid using an img tag in the HTML. The fact that they give the most sensible way of doing this as an example does not preclude you using other CSS to acheve the same result. Stuart. On Fri, June 8, 2007 9:21 am, Matthew Pennell wrote: This is an interesting one: If images must be used for list bullets, do so only using CSS, as with ul { list-style: url(arrow.gif) disc } Like a lot of people, I use CSS background-image to place a graphic at the top left of LI items, with a bit of left padding so the text makes space. What is the justification for this new 'rule' - how does background-image negatively affect accessibility in a way that graphical list-style doesn't? Matthew. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Stuart Foulstone. http://www.bigeasyweb.co.uk BigEasy Web Design 69 Flockton Court Rockingham Street Sheffield S1 4EB Tel. 07751 413451 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
On 08/06/07, Stuart Foulstone [EMAIL PROTECTED] wrote: I think the as with here means as example. The point is the use of CSS to avoid using an img tag in the HTML. The fact that they give the most sensible way of doing this as an example does not preclude you using other CSS to acheve the same result. That would make sense - it could probably do with being reworded so as to avoid confusion. Matthew, *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Use of PDFs - Accessibility issues
Many thanks to everyone for posts and personal replies on this thread. I appreciate you all taking the time to respond. The opinions that most people have kindly put forward are very similar to my own, but I guess that I wanted to make sure that I wasn't about to give an inappropriate 'knee-jerk' response to the client, or was unaware of options that might be appropriate. I intend making a counter-proposal along the lines that have been suggested and will let you know what happens. Regards, Nick Andrew Maben wrote: On Jun 7, 2007, at 6:16 PM, Nick Gleitzman wrote: Nick Roper wrote: Just to confirm, the recommendation from the agency is to replace existing html content with PDF version, not to provide PDFs as an additional alternative. Nick, you've made it fairly clear that your question is about accessiblity in PDFs, rather than whether or not it's a good idea to use them - but I'm afraid the most common answer you're likely to get is going to be: don't rely on them exclusively. The web is for HTML; the ability to deliver other file types is possible, but not the best option if accessiblity is desired. As printable alternatives, sure, I guess (but what's wrong with a good print style sheet?) - but I'm thinking of a number of Aust Govt sites which insist on delivering critical info as PDFs and even Word docs, which I find astonishingly short-sighted, as well as probably an abuse of accessiblity guidelines, if not legislation. What if I don't have Word installed (and why should I?)? The site may certainly need an IA overhaul, if it's been mangled over time by too many cooks - but that's no reason to stop using HTML in favour of PDF, surely. I think the site owners should have it pointed out to them that the agency's recommendations are simply out of touch with what's needed. From WCAG Samurai Errata: *We ban most PDFs*: PDFs that should be HTML are banned unless they are accompanied by HTML. All other PDFs have to be tagged. Andrew 109B SE 4th Av Gainesville FL 32601 Cell: 352-870-6661 http://www.andrewmaben. http://www.andrewmaben.com/net [EMAIL PROTECTED] mailto:[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] *** -- Nick Roper partner logical elements *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Use of PDFs - Accessibility issues
On Jun 7, 2007, at 6:16 PM, Nick Gleitzman wrote: Nick Roper wrote: Just to confirm, the recommendation from the agency is to replace existing html content with PDF version, not to provide PDFs as an additional alternative. Nick, you've made it fairly clear that your question is about accessiblity in PDFs, rather than whether or not it's a good idea to use them - but I'm afraid the most common answer you're likely to get is going to be: don't rely on them exclusively. The web is for HTML; the ability to deliver other file types is possible, but not the best option if accessiblity is desired. As printable alternatives, sure, I guess (but what's wrong with a good print style sheet?) - but I'm thinking of a number of Aust Govt sites which insist on delivering critical info as PDFs and even Word docs, which I find astonishingly short-sighted, as well as probably an abuse of accessiblity guidelines, if not legislation. What if I don't have Word installed (and why should I?)? The site may certainly need an IA overhaul, if it's been mangled over time by too many cooks - but that's no reason to stop using HTML in favour of PDF, surely. I think the site owners should have it pointed out to them that the agency's recommendations are simply out of touch with what's needed. From WCAG Samurai Errata: We ban most PDFs: PDFs that should be HTML are banned unless they are accompanied by HTML. All other PDFs have to be tagged. Andrew 109B SE 4th Av Gainesville FL 32601 Cell: 352-870-6661 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] Use of PDFs - Accessibility issues
I thing PDF may be delivery as a complement for save the doc to our computer. And should not be the single format for a web document, only if theres no other better way to display it. I thing there is no format to the web more complaint than a html web page. I like PDF when i want to save the dock to my computer to print or read later. But even read later i prefer to go to the web page, it could have been updated or have more useful comments. So i thing that marketing agency dont know nothing about web or web accessbility. If they know they should tell that should recommend PDF as a complement and not to replace HTML. Gaspar On 08/06/07, Andrew Maben [EMAIL PROTECTED] wrote: On Jun 7, 2007, at 6:16 PM, Nick Gleitzman wrote: Nick Roper wrote: Just to confirm, the recommendation from the agency is to replace existing html content with PDF version, not to provide PDFs as an additional alternative. Nick, you've made it fairly clear that your question is about accessiblity in PDFs, rather than whether or not it's a good idea to use them - but I'm afraid the most common answer you're likely to get is going to be: don't rely on them exclusively. The web is for HTML; the ability to deliver other file types is possible, but not the best option if accessiblity is desired. As printable alternatives, sure, I guess (but what's wrong with a good print style sheet?) - but I'm thinking of a number of Aust Govt sites which insist on delivering critical info as PDFs and even Word docs, which I find astonishingly short-sighted, as well as probably an abuse of accessiblity guidelines, if not legislation. What if I don't have Word installed (and why should I?)? The site may certainly need an IA overhaul, if it's been mangled over time by too many cooks - but that's no reason to stop using HTML in favour of PDF, surely. I think the site owners should have it pointed out to them that the agency's recommendations are simply out of touch with what's needed. From WCAG Samurai Errata: We ban most PDFs: PDFs that should be HTML are banned unless they are accompanied by HTML. All other PDFs have to be tagged. Andrew 109B SE 4th Av Gainesville FL 32601 Cell: 352-870-6661 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] *** -- Make it simple for the people -- http://www.artideias.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] WCAG Samurai Errata
If you use JS to write specific styles to the document, there should be nothing popping in and out. --- Regards, Thierry | www.TJKDesign.com How do you work that one out? Javascript cannot run until the page has (mostly) loaded, so I can vouch for getting a 'flash of extra content' on many of my pages. Since the hidden content cannot be re-enabled without JS on, I have to make the default appearance to be 'visible', then hide it asap. Mike *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] JAWS Screen Reader Demo - Monday 25 June 2007
We are doing another free JAWS screen reader demo on the afternoon of Monday 25 June 2007. A couple of the places are already booked but there are still six left. We limit the demo to 8 people so book early. The demo starts at 1:30pm and a free light buffet is available from 12:30 for those who want to come early. We are scheduled to finish at 5:30pm but you are welcome to stay afterwards to get some hands-on experience or look at some more websites. If anyone would like to attend this demo or a future one please fill in the form at http://www.accessibility.co.uk/free_jaws_demo.htm. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
On 08/06/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: How do you work that one out? Javascript cannot run until the page has (mostly) loaded, so I can vouch for getting a 'flash of extra content' on many of my pages. Since the hidden content cannot be re-enabled without JS on, I have to make the default appearance to be 'visible', then hide it asap. You can run scripts as soon as the DOM has loaded, so you very rarely have to put up with the flash of non-js content - that only really happens if you use the window.onload event. Matthew. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Out of Office AutoReply: digest for wsg@webstandardsgroup.org
Hello, Thank you for emailing me. I am currently out of the office on a team building activity and will return on Tuesday, June 12th. Please note that emails sent to my mail box will not be actioned until this date. If you require urgent assistance or action, please contact me on 040 442 4399. Many thanks Teale. --- This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities Suncorp. Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Use of PDFs - Accessibility issues
[EMAIL PROTECTED] wrote on 06/07/2007 08:04:01 AM: Anyway, to get to the point, the customer has now been advised by a marketing agency that the site should be reduced in size to approx 45 key pages, and that the majority of content for things such as conference room specification and rates, bedroom specs and rates, menus, events, golf rates, membership rates etc, should be made available in PDF form instead of the html pages that are on the current site. I'm curious. Has the marketing agency ever been questioned as to *why* the web content should be converted from HTML to PDFs? What are the business reasons for the recommendation? What are the usability reasons for this recommendation? Is there an ultimate cost savings in creation and maintenance of the site by using PDFs for the majority of the content? Will there be an improvement in accessibility for web users by converting the content to PDFs? What about those web users who may not have a PDF reader installed on their computers? (Yes, this last question may seem nutty but how times have their been discussions about web users who deliberately disable Flash content for whatever reasons? The concept could be the same for folks who disable PDF access as well.) Has the marketing company offered cost savings in providing the web content as PDFs instead of HTML? Have they compared costs when it comes taking content and publishing it as accessible HTML vs creating an accessible content (say in Word or some other accessible document) and converting that to an accessible PDF for publication on the site? Will there be a consistency in making sure all the accessible PDFs are created using the exact same methods and procedures? It sounds to me that the marketing agency is pushing marketing hype for its own benefit and not creating and easy to use, and accessible content by following the KISS Principle. Dennis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] WCAG Samurai Errata
On Behalf Of David Dorward http://www.tjkdesign.com/articles/toggle_elements.asp Despite the claims of the article, using document.write() will not work in XHTML[1] documents. Browsers don't support it in XHTML mode. You mean served with an application/xhtml+xml MIME type, but AFAIK, the article doesn't claim this. It simply says: This script should work in HTML and XHTML documents. As a side note, it also says: Earlier versions of this script did not use document.write(), I was using the DOM to plug the stylesheets in the HEAD element. Unfortunately, setting the rel attribute of the LINK element makes Safari go blank and STYLE fails in IE Win. So, I decided to go with what works! Anyway, IMO people who know enough to serve an XHTML document with a different MIME type depending on browsers, should be more concerned by my use of innerHTML in there than by document.write() ;-) --- Regards, Thierry | www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] WCAG Samurai Errata
From: Thierry Koblentz [EMAIL PROTECTED] uments. As a side note, it also says: Earlier versions of this script did not use document.write(), I was using the DOM to plug the stylesheets in the HEAD element. Unfortunately, setting the rel attribute of the LINK element makes Safari go blank and STYLE fails in IE Win. So, I decided to go with what works! That's a wise decision in this business. It might not win points in a standards forum, but if the goal is a working application with reasonable backwards compatibility, I'm with you. -- Al Sparber - PVII http://www.projectseven.com Extending Dreamweaver - Nav Systems | Galleries | Widgets Authors: 42nd Street: Mastering the Art of CSS Design *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Paul Chandley/HeadOffice/DHS is out of the office.
I will be out of the office starting 09/06/2007 and will not return until 13/06/2007. I will respond to your message when I return. For RRHACS web publishing requests, please contact the Web Services Team - (9096 2879, [EMAIL PROTECTED]). _ This email contains confidential information intended only for the person named above and may be subject to legal privilege. If you are not the intended recipient, any disclosure, copying or use of this information is prohibited. The Department provides no guarantee that this communication is free of virus or that it has not been intercepted or interfered with. If you have received this email in error or have any other concerns regarding its transmission, please notify [EMAIL PROTECTED] _ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Print style sheets
On 6/7/07, Lucien Stals [EMAIL PROTECTED] wrote: Hi all, I'd written a print style sheet for a site I'd done ( http://www.swin.edu.au/ads/ltshowcase/inspire/presentations.html ), but the feedback I got was that nobody knew it was there (unless they printed the page). So I hit google for some suggestions on how best to do this. This has lead to more confusion. One site I read suggested that print style sheets can confuse users when what comes out of the printer differs significantly from what they saw on the page. This is true in my case where I hide the navigation and some background images. I also change the font and justification to better suit print. So do people here think it's a good idea to have a print style sheet that differs from the screen style sheet? Yes! In the end, I used some javascript to allow users to switch between two style sheets on the screen. One is designed for the screen, the other designed for print. This way, if they print the page, they get what they see. What do people think about this approach. (If you are unclear from my description about how this works, just visit the page and toggle the print friendly view link near the top of the page). I definitely think it is important to let users know that the result from printing the page will be different than what they see on screen, only because a lot of users are used to wasting all their ink printing web pages that do not have print stylesheets, and think this is the norm. Whether it's a matter of explaining the feature to users or showing it on-screen, it helps the users who don't know about it. My approach has caused me a further problem: Because I used a link to trigger the script, clicks get added to the browsers history, when technically the user hasn't left the page. Any suggestions for how to get around this? Should I have used a select list? Isn't this problem solved by putting return false; in the event handler? Or am I missing something? -- -- Christian Montoya christianmontoya.net .. designtocss.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Accessible auto-submit dropdowns [WAS: Re: [WSG] WCAG Samurai Errata]
Matthew Pennell schreef: On 08/06/07, *Lea de Groot* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Fri, 8 Jun 2007 07:27:46 +0100, Matthew Pennell wrote: Auto-submitting dropdowns are not usable by keyboard users. More information, please? :) Auto-submit dropdowns mostly work by triggering the onchange event of the SELECT element. This is fired when you select a different OPTION using a mouse - however, if you are using a keyboard, it is fired when you press the down arrow to move through the list. You therefore can't select anything but the first OPTION, as it triggers the onchange event and submits the form. In Firefox you can use your keyboard in such case, but at least IE and Opera will submit on the first option. I've tried to write a script that offers auto submit, but still enables keyboard navigation. When a keyboard is used the submit is triggered on blur. In Opera hitting 'enter' can be used as well to submit as this is the browsers normal behaviour (in IE and Firefox hitting 'enter' only submits the form if the focus is on an input). Here it is (autoSubmit() needs to be called on load): function autoSubmit() { if (!document.getElementById) return; var selectNav = document.getElementById('selectNav'); if (!selectNav) return selectNav.onfocus = function() { this.origVal = this.value; } selectNav.onchange = function() { if (this.newVal) this.origVal = this.newVal; this.newVal = this.value; } selectNav.onblur = selectNav.onclick = function() { if (this.newVal this.newVal != this.origVal) { this.form.submit(); } } } form select name=selectNav id=selectNav option value=/option option value=1one/option option value=2two/option option value=3three/option /select form I briefly tested it in IE7, Fx2 and Op9, so it may need some tweaking for other browser. In real life there should (initially) be a submit button as well of course to grant access for those who have disabled JavaScript. Hopefully it is usefull to someone. cheers, Sander *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***