RE: [WSG] Doctype Javascript and accessibility
Thank you all for you suggestions. I think the older pages will go to Contribute as is, and loose any include page possibilities, unless they already end in .asp. The newer pages, I will use the template feature to recreate these. I can also look into reconfiguring of IIS to include handlers and includes. I act as webmaster, designer, and manager, without a real voice in anything. I have long been a proponent of all your suggestions, in web management. The website needs to be rebuilt from scratch in a series of smaller websites, with the marketing portion a priority. The trustees wanted a new look and almost hired a web developer, but do to many internal political issues, this has been put on hold and I created a new homepage. I could go on for pages and pages detailing the problems, issues, politics and lack of communication that reflects on this website. Being allowed to change to Contribute is a small victory. We are a Microsoft Shop, which is actually a double victory for Contribute. Nancy Johnson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Deering Sent: Tuesday, August 10, 2004 9:22 PM To: [EMAIL PROTECTED] Subject: RE: [WSG] Doctype Javascript and accessibility -Original Message- From: Of Nancy Johnson Thanks to Patrick and yourself for responding. I am beginning the process of migrating an existing web site from FrontPage to Contribute. I have always used the webbot feature for includes of footers and navigation. This is a website that has unfortunately multiple generations of html, and too many webpublishers with no experience are allowed to update content and more. Much as I would like to tear it down and rebuild it from scratch, it's not going to happen. I am having trouble with server side includes working with documents ending in .htm or .html. They only seem to work with .asp documents. This should be the default setting in the web server config; do not parse .htm or .html files as they are static HTML files and contain no server instructions. You can change this if you want/need, but then all htm/html docs will be parsed, making your server work harder than maybe necessary. Of course, if you have files with SS instructions in them that must be parsed, you could just change the filenames to .asp (and configure the server for redirects). I see your edu is using Microsoft-IIS/6.0. I haven't used it in a long time, but it should have most/all/more features of Apache. You could try and get the WebMaster to custom configure Includes, Handlers, etc, the IIS equivalent of http://httpd.apache.org/docs-2.0/mod/mod_include.html http://httpd.apache.org/docs-2.0/handler.html Such an approach should not be a hack. If you have a good team, I would recommend it is time to really sit down and take a look at the problems and try to look at a whole range of issues to try to move forward in a practical way. This includes developing proper server and content management policies and procedures. In most medium to large organisations, if this is not done at a reasonably early stage, it never gets done, because when it is not done, it grows out of hand, and the cost to re-establish proper web publishing and server management procedures just becomes to costly and time consuming to reengineer. As a consequence, many organisations run servers that are poorly optimised from a SDLC point of view (not a SysOp view). They are just a maze of hacks and poor policy. If you don't do this you will be adding hack after hack after hack. I just don't have the time to use the template feature in Dreamweaver to create multiple templates for the multiple generations of webpages, which means rebuilding each page. This is a sample of what I have been using: !--#include file=facheader.htm-- Any thoughts? In the distant past I used javascript to include a footer. It is only on one or two pages: http://www.wheelock.edu/news/NewsArchives.htm it is in the footer at the bottom. Here is a link to the actual javascript. http://www.wheelock.edu/news/newsfooter.js. Nancy Johnson It's not a good idea to try and generate content client side if you can do it server side, infact, in such instances it can't comply with WCAG1 P1 because it won't work where client side scripting is turned off, so if that function is designed to generate essential content, there is no graceful degradation path when applied to that context. Geoff Deering ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help
RE: [WSG] Doctype Javascript and accessibility
Thanks to Patrick and yourself for responding. I am beginning the process of migrating an existing web site from FrontPage to Contribute. I have always used the webbot feature for includes of footers and navigation. This is a website that has unfortunately multiple generations of html, and too many webpublishers with no experience are allowed to update content and more. Much as I would like to tear it down and rebuild it from scratch, it's not going to happen. I am having trouble with server side includes working with documents ending in .htm or .html. They only seem to work with .asp documents. I just don't have the time to use the template feature in Dreamweaver to create multiple templates for the multiple generations of webpages, which means rebuilding each page. This is a sample of what I have been using: !--#include file=facheader.htm-- Any thoughts? In the distant past I used javascript to include a footer. It is only on one or two pages: http://www.wheelock.edu/news/NewsArchives.htm it is in the footer at the bottom. Here is a link to the actual javascript. http://www.wheelock.edu/news/newsfooter.js. Nancy Johnson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent De Baere Sent: Monday, August 09, 2004 4:40 PM To: [EMAIL PROTECTED] Subject: Re: [WSG] Doctype Javascript and accessibility On Mon, 9 Aug 2004 14:27:32 -0400 Nancy Johnson [EMAIL PROTECTED] wrote: Does anyone know if a simple doctype javascript is accessible to text readers? First of all: what do you mean by doctype javascript? Second: what do you mean by text reader? A text-mode UA (à la lynx)? Screen reader software? In the first case (text-mode UA), it depends on the UA, however, IIRC lynx does not support javascript. Keep in mind that search engines too may not support javascript. That makes javascript-dependent navigation one of the worst ideas ever IMHO. In the second case it depends on the UA the screen reader is reading from. I can imagine MSIE to execute the code on page load thus enabling a screen reader to read the contents. However, I could be wrong on this one... The javascript would be similar to the following: snip document.write(); snip script tag Out of curiosity: why would you want content to be accessible depending on whether or not the user has javascript activated? The way you're writing those links to the page is causing me never to see it at all... . And if I want to contact you, i need to find my good old phone guide... . (heck, where's that one?) Vincent ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Doctype Javascript and accessibility
Nancy, Just a thought but I've experienced something similar (I think). I had files with includes using .shtml that worked with my index.html file. I changed servers and the new server was completely opposite. I had to change all my main pages to .shtml (index.shtml, etc) and my actual includd files were .html. Hope this is what you're looking for;. Sandie I am having trouble with server side includes working with documents ending in .htm or .html. They only seem to work with .asp documents. I just don't have the time to use the template feature in Dreamweaver to create multiple templates for the multiple generations of webpages, which means rebuilding each page. This is a sample of what I have been using: __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Doctype Javascript and accessibility
On Tuesday, Aug 10, 2004, at 22:46 Australia/Sydney, Nancy Johnson wrote: I am having trouble with server side includes working with documents ending in .htm or .html. They only seem to work with .asp documents. Change the file suffixes to .shtm or .shtml and your includes should work OK. BTW, the include file itself doesn't have to be a .htm file - in fact it shouldn't be. Consider, if the include file has the markup to make it a .htm file (ie html, head, body tags and all the rest), when that code is called into the destination file, it will duplicate what's already there. The include file itself can just be whatever code fragment you want to call into your pages, and saved as a .inc or even a .txt file. HTH Nick ___ Omnivision. Websight. http://www.omnivision.com.au/ ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Doctype Javascript and accessibility
Well, first of all...what do you mean by doctype javascript? Secondly, what happens when javascript is not available/enabled? Does it provide the page provide the same links even when the javascript is not executed? If not, no, it's not accessible. Unless I'm misunderstanding your intention, what you're trying to do should be done via server-side includes, not javascript... 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 ** The discussion list for http://webstandardsgroup.org/ Proud presenters of Web Essentials 04 http://we04.com/ Web standards, accessibility, inspiration, knowledge To be held in Sydney, September 30 and October 1, 2004 See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Doctype Javascript and accessibility
On Mon, 9 Aug 2004 14:27:32 -0400 Nancy Johnson [EMAIL PROTECTED] wrote: Does anyone know if a simple doctype javascript is accessible to text readers? First of all: what do you mean by doctype javascript? Second: what do you mean by text reader? A text-mode UA (à la lynx)? Screen reader software? In the first case (text-mode UA), it depends on the UA, however, IIRC lynx does not support javascript. Keep in mind that search engines too may not support javascript. That makes javascript-dependent navigation one of the worst ideas ever IMHO. In the second case it depends on the UA the screen reader is reading from. I can imagine MSIE to execute the code on page load thus enabling a screen reader to read the contents. However, I could be wrong on this one... The javascript would be similar to the following: snip document.write(); snip script tag Out of curiosity: why would you want content to be accessible depending on whether or not the user has javascript activated? The way you're writing those links to the page is causing me never to see it at all... . And if I want to contact you, i need to find my good old phone guide... . (heck, where's that one?) Vincent pgpVENMKu0SNh.pgp Description: PGP signature
