Managing Large Web Sites

Modifying Dreamweaver to produce accessible Websites: http://www.alistapart.com/stories/dreamweaver/ The Speed of Information Architecture November 14, 2001 "Information architects need to slow down!" http://semanticstudios.com/publications/semantics/speed.html Thoughts on building and maintaining large accessible Web sites My aim being is always to build good looking, quick to load, easy to use accessible Web sites. I am still working on it. One of the most important things I have learned on this journey of discovery is that site management is at the heart of accessible Web design. I have not read this particular assertion anywhere - but there can be no doubt about of it's importance. With a good 'content management system' Web sites are quicker and easier to build, easier to maintain and - if they are accessible to start with - more likey to stay accessible over time. A Web site management system will have at least some of the following features: Templates for consistent layout and navigation Abilty to produce multiple versions from the same content Ability to link with other programs such as WYSWYG Web design programs These are just a few features that I have picked out because they illustrate the importance of good information managent to the creation of accessible Web sites. Others features might inclue a built in scripting language, the ability to manage Web site via a browser, automated creation of navigation, workflow managemtent, discusion, search. Templates. The first Web sites I created were hand built one page at a time - laboriously re-creating each in turn in my favourite text editor (BBEdit if you must know 'software that does not suck' is their motto) and linking then so that I could click from one to the other, and back. I was happy for a short while - after all I was now publishing on the Web. But once I had got beyond about 3 or 4 pages this method was starting to look like a lot of work. Quickly I realised I could use one of my pages as a template for the next one - and this helped to give my site a more consistent look and reduce my workload a bit. When I needed to make changes across several files simultaneously the find and replace features of my text editor came to my rescue - very handy given the number of changes I tended to make to a site once I'd got beyond the initial build - and much quicker than making the changes one at a time by hand ( particularly if you have a Web site with hundreds of pages). I was heading in the right direction - but maintaining sites built in this way was still taking a long time and find and replace can be a very blunt instrument often altering parts of the page other than those intended and worse than useful if the text on pages ever got out of sync. Not being one for doing uneccessary amounts of work I started to look around for a better way to build and manage my Web sites. Most of the WYSIWYG Web editors had a degree of site management built in to the product - but what I wanted was something who's principle strength lay in this area. And in any case I wasn't a keen user of Web design programs - preferring to retain complete control over all of the HTML in a document. The one I finally settled on was a product called Frontier - that allowed me to store all the content of my Web site in a database but still generate 'bog standard' HTML file and have them stored on the file system to be served by any conventional Webserver. One importantly feature of Frontier was that it allowed me to either have a single templates for my entire site - or have different templates for different parts of the site. (I am reluctant to be seen recommending a particular product - but the important point is if you are managing a large Web site you need to find something that suites you - you can find a list of Web content managment products at: http://www.camworld.com/cms/) As I have been heard to say on numberous occassions "Building accessible Web sites is really at it's heart an 'information management' problem- and when it comes to solving this particular problem we need the right tools. The amount of information we are likely to deal with can only increase - and the demand for this information to be available on an array of different devices is also likely to increase . A system that allows us to flow content into templates makes for more efficient site manager and makes it easier to build flexibel accessible Web sites. Here is a quote from an article by Duffy Marson in an articles I came across on the Internet called Web site accessibility goes mainstream talking about how difficult it can be to make Web pages accessible - if it has not been 'built-in' from the start, "Companies that get serious about Web site accessibility find it to be a time-consuming and iterative process. Even with the new automated tools, Web developers will spend a couple of hours per page diagnosing and fixing accessibility problems. Static Web pages are easier to fix than dynamically generated Web pages, and pages built from templates are easier than those without templates. " CAROLYN DUFFY MARSAN http://www.nwfusion.com/news/2001/0611specialfocus.html I don't necessarily agree that dynamically generated pages are any harder to fix - but that aside - there is a clear message that templates are a good thing. They are good because they make managing your site easier, help to provide a consistant look and feel to your pages (that in itself makes them more accessible) and by making sure your templates are written in accessible HTML in the first place means you are already half way down the road to making sure your entire site is accessible. Jim Thatcher discussing way to allow people using screen readers to jump over the long lists of navigation links that tend to be the first things that users encounter on a Web site:, "The simple anchor defining "Main" is just above the main content. Note that the anchor itself has no content. The advantage of this method, independent of that fact that it doesn't alter the visual appearance, is that it can be included in the template of the site, reducing to zero the continuing cost of implementing this crucial accessibility feature. " Producing multiple versions from the same content Templates are also essential if you need to utilise the next feature of a good Web content management systems - the ability to produce multiple versions from the same content. If building accessible Web sites is about accomodating the diversity of the visitors to your site - at some point you have to ask yourself "just how much diversity can I accomodate - and how will I do this". Everyone in the world is different - so at that the ideal is that you accommodate this difference by serving up a page to each individual that is tailored to their idividual needs ( i.e as many versions as there are people in the world). On the opposite site we could try to serve up a single version that is flexible enought to accomodate all potential visitors. The first suggestion is of course impossible and not necessary - the differeces between the preferencees of the largest percentage of our visitors are probably not so great as to warrant such action ( having said that of course many site now allow visitors to re-arrange the design and content of pages to suit their own tastes). The reality is however that for most most Web developers even maintaining two version proves impossible - never mind several versions. The number of text only pages that have never been updated since the the launch of the Web site are a testament to this fact. The World Wide Web Consortiums Web Accessibility Intitiative recognises this problem advocates that alternative versions of a site should only be published as a last resort - to be considered if you cannot make your 'main version' accessible to everyone. I agree that this is a good principle - but I think there are some problems with this stance. The assumption here is that it is always the presentation that is critical to making the Web page content accessible or not accessible to visitors to the site - i.e the content itself does not have to be changed. There are groups with particular needs who for the most part cannot be accomodated by a single version - people with cognitive or profound learning disabilities be the one that comes to mind. People using the myriad of devices now connected to the Internet are another - but not designed to accomodate HTML. In theory if you build your pages according to W3c HTML standards - and divorce presentation from structure ( by using style sheets - which I will look at in a later chapter) many of these devices will be able to view your content. In practice this does not seem to be true. As new internet devices are hitting the market - new markup languages are being invented customised to the needs of these new devices. HTML is not being seen as the universal markup language by all vendors. As a general principle I support the idea that a single version of a Web site that can be flexible enougth to accomodate all audience is the thing to strive for. But I am not totally convinced that there is never an occasion where a completely tailored version - both were the same information is flowed throught a different template - and where both the content and the presentation needs to be different - is not useful. Most content management systems - if the are any good make the former suggestion fairly easy to automate. The later unfortunately tends to require specialist input and more resources in terms of time and money. I don't know how we solve this - but I think it is worth being aware that that even when you comply fully with the W3c Web accessibility guidelines there are still going to be people who will not be able to access your content. Do we take a pragmatic approach or should we insist that all information should be available to all people? If we decide to take the later course there are likely to be additional costs (and I haven't even mentioned that not everyone's first languages is english)? Is it legitimate to approach look at this problem by saying 'my Web site is aimed at a very specific audience - which doesn't include people with learning difficulties? One thing I would say is that if a Web site meets the needs of the audience you are trying to reach - then that is one important feature of an accessible site. But is the only obligation of the publisher to design for this specific audience the site is aimed at - even if that means it is innaccessible to everyone everyone else. In other words it is ok to have a site that is full of jargon and language that will only be understood by a particular 'in the know' group and it is ok to design an innaccessible Web site if it is only for an audience of other designers? Well the first thing I would say is that it seems to make the assumtion that there are no disabled people employed in the particular organisation or profession that their site is aimed at, - an unlikely assumption given the percentage of disabled people in the every population - approximately 20% in most countries of the world if my memory serves me right. Ability to link with other programs Although I don't use WYSIWYG Web design programs myself there is no getting away from the fact that they are used by the majority of Web site designers. I can see that in terms of designing the look of a site - the layout, graphics etc programs like Dreamweaver are very useful and powerful. Web designers are not going to stop using them tomorrow because they have heard me say today that they make it more difficult to design accessible sites. In my opinion you cannot currently build a fully accessible HTML validated Web site without you or the person you have passed the task to knowing how to write HTML - and of course having knowledge of how to create an accessible site. The solution I would recommend therefore is to design the layout and look of the site in a WYSIWYG program but also take advantage of the more powerful site management facilities that are available in programs that are designed specifically for this purpose. That is why if you are looking at site management systems the ability to link up with external applications is an extremely useful feature. If the conent management system can link up to an external text editor with support for writing HTML by hand even better. There are numerous ways to create Web pages including some of which I have mentioned: writing HTML by hand, saving Word Processing pages as HTML, creating pages using WYSIWYG (What you see is what you get) Editors like FrontPage or Dreamweaver, using text to HTML conversion tools, and using web site automation and management tools. In general automatic HTML conversion tools and WYSIWYG do not produce accessible Web sites - human intervention is still needed on many occasions. Why? Because at the heart of the transformation process is the desire to reproduce the presenation rather than the structure of the original document.Cynthia Waddel in 'The Growing Digital Divide in Access for People with Disabilities: Overcoming Barriers to Participation' (http://www.aasa.dshs.wa.gov/access/waddell.htm) Why does this matter? Who says exising tools do not produce accessible Web sites: Cynthia Waddell: "The digital divide in web page transactions and the Internet environment has bred a host of additional problems for people with disabilities.Ã!=  For example, commercial web-authoring applications lack access tool kits for webmasters to correct accessible web design problems.Ã!=  In fact, many current web-authoring tools on the market make it extremely difficult to even design an accessible web page.Ã!=  The scarcity of tools also contributes to the lack of education among programmers and web authors on why and how to code an accessible web page.Ã!=  And if the webmaster herself is a person with a disability, she will also find a lack of web authoring applications that she can utilize.Ã!=  This is especially true for webmasters with mobility disabilities requiring voice, eye tracking or keyboard input/output features in web authoring applications.Ã!=  "http://www.aasa.dshs.wa.gov/access/waddell.htm This was written in 1999 - tools have move on a bit - and although there are encouraging signs that software vendors are starting to take the accessibility issue seriously (mainly due to the introduction in America of Section 508 part of the Rehabilitation Act of 1973, which requires the federal government to buy and develop information systems that are accessible to people with disabilities.). Companies such as Apple, Microsoft, Adobe, Macromedia, Compaq Computer, Hewlett-Packard and Booz Allen & Hamilton are now taking this issue seriously in terms of the Web sites that I visit every day on the Web we have still got a long way to go. The World Wide Web Consortium have published a set of guidelines for companies creating HTML authoring tools (http://www.w3.org/TR/WAI-AUTOOLS/). These guidelines no doubt are forming the basis for changes to the major authoring tools and browser manufacturers. But we are not there yet Discussion on hte W3c mailing list in May 2001 Having carried out accessibiltiy audits of numberous Web sites created by WYSIWYG editors I have found the main problems to include: Improper use of HTML - No Headers, no paragraph tags - documents as a consequence lack structure Use of HTML tags for presentation rather than structure improper use of style sheets - creating presentation Overuse of Font tag Complicated layouts using nested tables lack of alt attributes for non text content - or inappropriate alt attributes, e.g. alt tags that contain the name of the image file or contain the text 'image'. scripts that do not work across different Web browsers and hardware platforms If you are building the Web site yourself or if you use one of the specialised Web page development programs the World Wide Web Consortiums Web Accessibility Guidelines provides a good guide to help make your site accessible ( http://www.w3.org/WAI/). Your choice of WYSWYG Web editor should be be based on whether it can assist you in the creation of accessible pages and whether it lets you edit the resulting HTML. If you decide to enlist the help of a commercial design agency you should ask them if they have experience of creating accessible Web sites and to give you the addresses of some examples. If their eye's glaze over or if there is a stunned silence on the other end of the phone when you ask this question try somewhere else. It is not just about building HTML pages In reality if you are building and maintaining a large Web site you need a combination of tools which can help you to automate the process - but still allow you to delve in to hand code when needed. One of the most important issues of running a Web site is not about how you create the HTML but how you design systems that make it as easy as possible to let contributers add, modify and delete the documents they have ownership of, manage the file system etc - and still make the end result accessible. Here is a rather long quote from Philip Greenspun that hints at some of the problems: Why don't these what-you-see-is-what-you-get (WYSWYG) HTML editors enable everyone to become a competent Web publisher? They solve the wrong problem. In the early-ish days of the Web, say 1994, it was observed that college undergraduates who were Unix users could build themselves a Web page in about 30 minutes, even if they were English majors who had never taken a programming class. Users of desktop PCs were unable to produce Web pages at all. Software developers set out to solve what they thought was the desktop user's problem: HTML "programming" is too hard to learn. He goes on, It turns out that HTML "programming" consists of sticking "<I>" and "</I>" around a word that you want to appear in italics. Secretaries worldwide were successfully using word processors like this all through the 1970s. Had the average person really become so stupid and lazy in the succeeding 20 years that he couldn't learn that "the I tag is for italics; the B tag is for bold"? In Alan Cooper's interesting book on user-interface design, About Face (1995; IDG), he makes the claim that users don't understand the difference between RAM and disk and further, that they don't understand the file system or directory hierarchies. Somehow people struggle along and get a letter printed but they are confused when they close a document and their word processor asks them if they'd like to save their changes. Save them where? Why weren't they saved before? Why is there a "file" menu on a typical program at all? Shouldn't I just be working on a document and be offered the chance to revert to older versions? Building a Web site exposes and exacerbates all of the problems that users have with their computer systems. No longer are they just trying to print out a letter. They have to organize and link together a set of documents. So if you give someone a WYSWYG editor for HTML, he or she will usually just get stuck 30 minutes deeper into the task of building a site. For large sites as I have argued specialised Web site management system is essential - by specialised I don't mean built to order I mean a product whose strengths lies in this area. Something which will allow you to design common templates with dynamic elements, some automated HTML, scripting capability, allow you to manage and easily change the directory structure of your site, perhaps allow you to link in with other HTML generating programs. So I am not saying "if you want to have an accessible Web site you are going to have to built it all by hand". What I am saying is that we need to be aware of the limitations of automated WYSIWYG Web publishing systems. What is needed is a combination of both automated, 'make my life easier' software, and knowledge - of both accessibility issues and Web Publishing technical details. There is much more to be said about this, but not in this document. For a more detailed discussion it would be worth having a look at Welcome to the `new Web order' by By Jeff Walsh and Matthew Nelson ( http://www.infoworld.com/cgi-bin/displayStory.pl?/features/990208weborder.htm). {imageRef ("UniGardens12small", "University Gardens No. 12", title: "University Gardens No. 12")} Once you have created you Web site there are many tools you can use to evaluate the accessibility of the resulting pages. The World Wide Web Consortiums Web page: Existing Evaluation and Repair Tools provides a good list of what is available (http://www.w3.org/WAI/ER/existingtools.html). Web creation software - assuming they are built in conformance to the guidelines - should automatically include accessibility feature into Web pages. Here are some tools that I use: HTML Tidy: A must have application for any HTML author; cleans up HTML and fixes mistakes and a host of problems and points up some accessibility problems. Has built in support for cleaning up HTML produced by Word 2000 and Word 97. URL: http://www.w3.org/People/Raggett/tidy/ Bobby Accessibility Checker: Using Bobby will tell give you a good idea of how well your pages conform to the World Wide Web Consortiums Web Accessibility Guidelines. Using [OE]Bobby[base '] is only a start it is not able to point to all your access problems and does not work correctly on sites that use Frames. URL: http://www.cast.org/bobby/ Lynx Browser: Always check your pages using a text browser; Lynx is the best. http://www.trill-home.com/lynx.html Betsie is the filter program used by the BBC to create an automatic text-only version of its website. There are other programs that can convert an design based page to text only [OE]on the fly[base ']. URL: http://www.bbc.co.uk/education/betsie/ ---

[ Register for updates ]

Just testing the lates version of commentIt.
--Jim Byrne ( j.byrne@gcal.ac.uk ) from UK on 4/3/02; 2:31:00 PM