nof-digitise Technical Advisory Service

NOF-digitise
Technical Advisory Service
2001 - 2004 archive

Latest Additions

Introduction

Archive Introduction

Why an advisory service?

What can it help me with?

Frequently Asked Questions

The questions and answers on this page have been asked by nof-digitise applicants. This page will be updated frequently.

Web site design

Web Site Design

1. Will you be preparing advice on colour to ensure that people looking at their computer screens will actually see images with the same colours as the originals?

Ensuring exact consistency in how images are displayed across the range of machines to which the content will be delivered is difficult to achieve given that there are a wide range of different types of display devices in use.

In practice existing projects do tend to create several different formats and sizes for images, e.g. SCRAN display 72 dpi, 256 colour JPEGs on the Web, with 150 x 150 pixel thumbnails. Information about the SCRAN solution to this can be found at
http://www.tasi.ac.uk/resources/scran.html

2. Will NOF provide guidance on screen size, screen resolution and size text?

It will be difficult to provide NOF projects with guidance on screen size, screen resolution and size of text. Although modern PCs provide high-resolution graphics capabilities, significant numbers of users may continue to use older PCs. In addition we are currently seeing development of a range of devices for accessing Internet resources which have limited display and graphical capabilities, such as Internet-enabled TVs, PDAs, mobile phones, etc. In addition people who access NOF resources may have particular requirements (visually-impaired, colour blind, etc.) NOF projects should ensure that their services can be accessed in a device-independent way, although enhanced services which will exploit the end users PC setup or personal preferences may be provided.

3. What about using different languages and type faces on our Web site?

This is an area the NOF Technical Advisory Service is looking into. The following resources may be of use:

http://www.laptopchallenge.org.uk/
http://mkdoc.com/features/i18n/

4. Can you provide advice on the advantages of static versus dynamic Web pages?

The terms "dynamic Web pages" and "dynamic Web sites" can be used in a number of senses, so it is important to clarify the meaning.

The term "dynamic Web page" is sometimes used to refer to pages which contain moving images or scrolling text. Such pages may simply use dynamic GIFs, may use multimedia formats such as Macromedia's Flash technology or may make use of a language such as ECMAscript (JavaScript) or Java.
The term "dynamic Web site" may also refer to Web sites which provide interfaces to search facilities or backend databases, in which server-side technologies (such as CGI) are used to interrogate databases, file store or legacy systems held on the server and display results based on a user query; for example a Web site which provides access to a library OPAC.
The term "dynamic Web page" may also be used to refer to pages which may be personalised for the end user, either by the end user selecting preferred options or by the system choosing the preferred options based on the end user profile. An example is the My.Netscape service (which allows users to select the resources which are displayed, from options such as weather information, news, horoscopes, etc.).
The term "dynamic Web page" may also be refer to pages which are personalised for the end user's device or browser. For example, different pages may be sent to Netscape and Internet Explorer browsers, to users of browsers for the visually impaired, WebTVs, PDAs or WAP phones.
The term "dynamic Web page" may also be refer to pages which will alter based on actions by the end user. For example a menu may expand as the user moves the cursor over the menu item. This approach is normally provided by use of a client-side scripting language such as ECMAscript (JavaScript) which will manipulate HTML and CSS elements based on end user actions, such as mouse movements and mouse clicks. The term "Dynamic HTML" (DHTML) is often used in this context.
The term "dynamic Web site" may be used to refer to a Web site which makes use of a server-side scripting environment such as PHP or ASP (Active Server Pages) or a content management system such as Zope or ColdFusion. It should be noted that such technologies may be used to provide dynamic Web pages (as defined in 1-5) but they may also be used to provide static Web pages.

Movement on a Web page (example 1) may be useful in some cases. However, for accessibility purposes, the end user should be able to switch off scrolling text or moving images.

Access to search facilities, backend databases and legacy systems (example 2) is desirable on many Web sites.

Web sites which can be personalised for the end user (example 3) may be desirable in some cases.

Web sites which can be personalised for the end user's client environment (example 4) may be desirable. However users should not be disenfranchised if they have an unusual client environment.

Dynamic Web sites (example 5) may be desirable in some cases. However users should not be disenfranchised if their browser does not support ECMAscript, or if ECMAscript is disabled (e.g. for security purposes).

If you are considering developing a dynamic Web site you should consider the performance implications and the effect on caching. Will the performance of your service deteriorate if, for example, server-side scripting is used, or will the performance on the end users PC deteriorate if it is not powerful enough to support Java or ECMAscript? In addition will pages on the Web site fail to be cached and what will effect will this have on the performance for the end user?

You should also consider how easy it will be to cite and bookmark dynamic resources. Will resources have a meaningful URL which is easy to remember? Will bookmarked URLs return the same resource at a future date?

For further information on Dynamic HTML see DHTML Lab at http://www.webreference.com/dhtml/

For a definition of Dynamic HTML see the What Is site at http://www.whatis.com/WhatIs_Definition_Page/0,4152 ,212022,00.html

5. Are there any standards in relation to people with disabilities?

NOF projects should conform to W3C WAI guidelines. The Bobby Web service and Bobby Java application will help in monitoring compliance with the guidelines. See <http://www.w3.org/WAI> for further information.

6. I plan to use a piece of proprietary software to create the HTML for the web sites, and will be checking with the manufacturers to find out how well it fits the NOF technical standards. However, I do know that it does not make use of cascading style sheets to control the appearance of web pages. Instead it enables the web master to specify background/font colours and font sizes, page widths/heights etc. in a background "document" which is then referenced by every single new web page created - thereby splitting out web page content from design, achieving the same effect as CSS but in a different way. Will this still be acceptable to NOF?

We do recommend that CSS are used (see section 5.1.1) although it is not being insisted upon (this is a *should* rather than a *must*). If you can justify the reasons that you have decided against them then that's OK. We would say though that your solution does (at first sight) sound a bit cumbersome and potentially ties you to that piece of software for ever, and we do recommend against using proprietary software unless absolutely necessary.

7. Do you have any specific guidance about how we can ensure that web sites are compatible with PDAs? (Unfortunately our budget won't stretch to purchasing one so that we can work out what is needed.)

It is not necessary (or always desirable) to purchase and test Web pages against every combination of hardware device, browser version etc. Instead you should check that your Web pages are compliant with the version of HTML / XML / CSS that you use.

The testing should be carried out using a HTML / XML / CSS validator rather than relying on checking how it looks using a browser. A variety of validator are available - for example see the HTML and CSS validators at http://www.w3.org/.

In addition to these (and other) Web-based validators, many authoring tools will have their own validators.

There are a number of validators available for WAP phones. These may be bundled in with WAP / WML authoring tools.

There may be similar tools available for PDAs. However if the PDA supports HTML, you will be able to use a HTML validator.

Note that there are a number of WAP emulators available - e.g. see http://www.gelon.net/. These can be used to test out WAP sites. However, as stated above, it cannot be guaranteed that if a site works correctly in an emulator that it will work in the device itself.

8. Although we appreciate the importance of standards, we feel that we cannot implement them fully within our project. The NOF-digi Standards document mentions that if this is the case we should document a "migration strategy" in our project report. Can you explain what is meant by this?

You should provide full details of failure to comply with standards, and also any instances in which you feel the need to implement solutions which may not comply with best practices.

In your report your should provide detailed information which will inform your NOF-digi case manager and associated bodies. You should justify the decisions you have made, show that you are aware of potential problems by outlining the disadvantages (as well as summarising the advantages). You should also describe how you would move to a more standards-compliant solution or implement a better solution, the costs of doing this, and how the work could be funded.

You should be aware of the different approaches which can be taken in migrating resources to open file formats: you could use software to convert files from one format to another; you could provide an emulation environment; you could redigitise your resource; etc. In your migration strategy you should outline the approach you are likely to take.

Two examples are given below.

Example 1 - Use of Flash

Compliance With Standards

Please document areas in which your project may deviate from compliance with the NOF Technical standards. In this section you must (a) describe the areas in which compliance will not be achieved; (b) explain why compliance will not be achieved (including research on appropriate open standards); (c) describe your migration strategies to ensure compliance in the future and (d) how the migration may be funded.

(a) Area in which compliance will not be achieved

We will be providing an online game on our Web site. This is aimed at children. The game (on our Victoriana Web site) will allow users to dress images of Victorian dolls from a selection of costumes.

(b) Explain why compliance will not be achieved including research on appropriate open standards)

The Standards document request us to make use of appropriate open standards. In this area we believe the appropriate open standards are XHTML and ECMAScript (JavaScript), sometime known as JavaScript.

We would like to implement a solution similar to that given in the HTMLgoodies Web site at <http://www.htmlgoodies.com/beyond/dhtmlandscape.html> (taken from <http://www.htmlgoodies.com/beyond/dhtml.html>) or the Mr PotatoHead which is linked from < http://www.gse.harvard.edu/~t525_web/lab_mater ials/javascript_dhtml/jav ascript_pt1_pub.html>.

However since our online game is only a very minor part of our NOF-digi project Web site and we have already developed a solution in Flash, we intend to make this available in the short term.

Our proposed Flash solution will be easy to implement as similar work has already been carried out. It will be usable by modern browsers which have a Flash plugin.

However (a) it is a proprietary solution; (b) it may not be accessible; (c) it will probably not work on non-standard devices, such as a digital TV.

(d) Describe your migration strategies to ensure compliance in the future

As part of the NOF-digi work we will be building up our technical expertise. As we develop in-house technical expertise in client-side scripting (ECMAScript/JavaScript) we intend to migrate our online games to make use of Dynamic HTML

(e) Describe how the migration may be funded

This will be funded by our organisation, as part of our inhouse resources which will be ensuring that our Web site conforms more fully with accessibility guidelines.

Example 2 - Use of An Externally-Hosted Service for Web Statistics

Compliance With Best Practices

Please document areas in which your project may not implement best practices or in which a compromise solution is proposed. In this section you must (a) describe the areas in which best practices will not be achieved; (b) explain why best practices will not be achieved; (c) describe your migration strategies in case of problems and (d) how the migration may be funded.

(a) Area in which best practices will not be achieved An externally-hosted service (company X at Web site http://www.xxx.com/) is proposed from providing realtime access to usage statistics.

(b) Explain why best practices will not be achieved This is a risk associated with use of externally-hosted services (especially those which provide services for free): the service may go out of business; the service may introduce charging; etc. A worst case scenario is that the service goes out of business and its domain name is taken over by a porn company. A small pornographic icon could then be included on our Web site!

The best practice solution would be to provide analysis of usage statistics locally. This could be achieved by using a Web analysis package (e.g. Web Trends at <http://www.webtrends.com/>). There is a cost associated with purchasing the software and resource implications in using it (rotating log files, managing large files, etc.). We do intend to analyse our own Web server log server files. However this will be for internal use and will not provide (a) realtime access and (b) detailed statistics such as browser functionality.

The use of an externally-hosted usage service is: (a) cheap (free); (b) requires no special technical expertise (HTML code has to be added to our pages); (c) requires no software or hardware to be installed and maintained locally and (d) provides usage statistics on browser and client machine functionality which is not provided by analysing our server log files.

This approach has the following disadvantages: (a) reliance on a third party, which we have no formal contractual arrangements with; (b) only provides usage statistics for graphical browsers; does not allow statistics to be easily reused (unless the licensed version of the service is purchased).

(d) Describe your migration strategies in case of problems

The company we intend to use has been in business since 19xx. We have been in email contact with them and they have reassured us of the financial reliability of the company. They have agreed that if they change the conditions of their service they will give us at least one month's notice.

The links to the externally hosted service will be managed within our Content Management System (or through use of Server-Side Includes). This will enable links to the service to be switched off be editing a single file.

Access to realtime usage statistics is a value-added service. Our project will continue to provide its deliverables if this service becomes unavailable.

We would lose usage data which is held by the company. However (a) we could purchase a licence for this service which would allow us to access our data and import it to a spreadsheet and (b) we still have usage log files held on our Web server.

(e) Describe how the migration may be funded. If we feel that we still require realtime usage statistics we will probably want this across a range of our organisational Web sites. We would therefore purchase a licensed package such as Web Trends Live (see <http://www.webtrends.com/products/wtl/>).

Some Useful Links

Risk management of Digital Information: a File Format Investigation - http://www.clir.org/pubs/abstract/pub93abst.html

Avoiding technological Quicksand: Finding a Viable Technical Foundation for Digital Preservation - http://www.clir.org/pubs/abstract/pub77.html

Migration: a Camileon discussion paper - http://www.ariadne.ac.uk/issue29/camileon/

Archiving and Preserving PDF files - http://www.rlg.org/preserv/diginews/diginews5-1.html#fea ture2

Flash and SVG - http://www.ep.cs.nott.ac.uk/projects/SVG/flash2svg/

9. Can we use Javascript and DHTML on our NOF-digitise Web site?

The use of client-side scripting (including javascript and DHTML techniques) is acceptable, however please take note of the following points:

1) The site must still be accessible to browsers which are not scriptable. Use <noscript>< tags and "sniffer" routines to determine the client capabilities and provide content-equivalent pages to non-scriptable browsers.

2) Thoroughly test your pages for functionality under a wide range of browser / platform configurations.

A few general comments on client-side scripting:

There Is More Than One Javascript...
Javascript is supported in various flavours on browsers according to version and manufacturer. "Javascript" is the name given to the scripting language developed by Netscape and has also come to mean the generic client-side scripting language. JScript is the Microsoft equivalent. ECMAscript is the published open standard, to which proprietary flavours of the language _should_ adhere. Note however that ECMAscript defines the underlying structure of the language, but not specific issues, which are addressed by the Domain Object Model. The DOM too has a standardised structure, defined by the W3C group.

Internet Explorer also supports VBscript, based on Visual Basic. This will not work in other browser versions.

( ECMA = European Computer Manufacturing Association )

USE "language" Attributes in <script> Tags:
The version of javascript can be specified in the SCRIPT tag. This can be useful for branching code, particularly when used in conjunction with the "src" attribute'.

DHTML: What Is It?:
The term DHTML (Dynamic HTML) is a marketing term which denotes the use of a client-side scripting language (normally JavaScript/ECMAScript) to manipulate HTML and CSS properties.

Use of DHTML is compatible with the open standards developed by W3C, and so its use is OK from a standards point of view.

<noscript> Tags:
Use <noscript> tags where appropriate to deliver equivalent content to browsers which do not support javascript or where script processing has been disabled.

Accessibility:
Regardless of how javascript is used on the page, the overriding principle for NOF projects is that the page must still be accessible to non-javascript enabled browsers.

Future Proofing:
As new versions of browsers are released and new ways of accessing web resources come into existence there is a need for projects to test their content against these new interfaces. This is true for all web content, but the situation is more acute when pages include script. Projects should build into their plans a provision for undertaking these checks and for making corrections to HTML and script as necessary.

Script Block Content Shielding:
Commenting within <script>tags to prevent inclusion of the script by browsers that do not understand the <script> tag. Wrapping the text in HTML comment tags prevents these browsers from displaying raw javascript on the page. Admittedly this is highly unlikely now, however it is good defensive programming practice.

Browser Detection Aka Sniffing:
It is superior to test for the component of the DOM that you wish to use rather than parsing the navigator.userAgent property. For example, to create a rollover script for images, you would code:

if (document.images){
file://image loading / swapping routine
}

Proportion Of Javascript-Enabled Browsers:
Figures for the numbers of javascript enabled browsers are difficult to interpret. These figures can be derived in two ways: by making assumptions based on the userAgent or by placing a testing script on a web page and recording results. Measuring from the userAgent value can be done from the server access log but it takes no account of the setting of the browser, so the assumption that, say IE5.5 is javascript enabled is not always true. The nimda virus outbreak last year highlights this. Many people were advised to turn off scripting in their internet settings to protect themselves from nimda.

Further Resources:
http://www.dhtmlcentral.com
http://www.devguru.com/Technologies/ecmascript/quickref/javascript_int ro.html
http://developer.netscape.com/js/
http://www.w3.org/DOM/
http://www.ecma.ch/ecma1/STAND/ECMA-262.HTM

10. What exactly constitutes an acceptable minimum level of browser for support purposes?

The Technical Standards currently states "Web services must be accessible to a wide range of browsers and hardware devices (e.g. Personal Digital Assistants (PDAs) as well as PCs). Web services must be usable by browsers that support W3C recommendations such as HTML, Cascading Style Sheets (CSS) and the Document Object Model (DOM)."

We have deliberately left this fairly open and avoided listing specific browser types and specs because we would like projects to try to make their sites/resources as accessible as is possible and this may differ from project to project.As a guideline I would recommend that you make sure that you support at the very least Netscape/IE 4.x upwards. I would also recommend that your CMS supplier has a look at the WAI site where a good list of alternative browsing methods are available. The resources available from there will allow you to see if your site works well with screen-readers, voice browsers etc.

http://www.w3c.org/WAI/References/Browsing

Some of the FAQs may also be of use. See Web site design no 7

11. How do we register domain names for our site?

This is an important part of setting up your Web site and it is probably useful to read some background information before you start any registering.

Background and Term Definitions

Registry: the organisation responsible for administering a top-level domain. Like Nominet for .co.uk names.

Agent: an affiliate or partner of the registry that accepts requests for domain names and administers ownership of a domain, also know as a registrar.

Registrant: the registered owner of a domain.

Domains are divided into TLDs (top-level domains) and ccTLDs (country code top-level domains). There is an administrative body - the "registry" - to oversee the TLDs, and each ccTLD. Terms and conditions vary amongst them.

ICANN administer the TLDs : com, .net, .org etc, and DNS in general: Internet Corporation for Assigned Names and Numbers at http://www.icann.org/.

It devolves authority for naming to the Internet Assigned Numbers Authority (IANA)

In the UK, .uk is administered by http://www.nic.uk/. You can register a .co.uk site directly with Nominet or register through one of their agents - aka Nominet members. Direct registration is around £80+VAT for a two year period. Nominet members receive a huge bulk discount - £5+VAT for 2 years.

Terms and conditions for registering a .co.uk name are given at http://www.nominet.org.uk/ref/terms.html.

Generally these 2 sites have quite a lot of useful information on them that it would be helpful to read. This can be accessed from http://www.icann.org/general/faq1.htm and http://www.internic.com/faqs/domain-names.html.

General points and guidelines concerning domain registration and administration

To register a domain name it is necessary to approach an "agent" (aka member, registrar) of the registry that controls its TLD. Many "agents" can exist for each registry, with ICANN and it's partners ensuring, behind the scenes, that the namespace remains unique - no duplicate names are allowed.

The registry is responsible for setting up your domain name on the Domain Naming System (DNS). DNS generally describes the way that (domain) names are mapped to IP numbers, The DNS system has at its highest level in the namespace hierarchy a system of "root" servers. This is where a request for a domain name resolution is initiated. The root servers will give the location of the primary and secondary name server that is "authoritive" for your domain. It is this link, from the root server to the name server that the agent maintains and alone can modify.

For top level domains: the domain registration has 3 separate contact fieldsets. These are the "technical", "administrative" and "billing" contacts, alongside the owning individual or organisation's details. The same details can appear in all three contact types.

The content of a domain registration is different amongst ccTLDs. However they all have in common the owner (registrant) details and the location of the nameserver.

Requests to modify the nameservers for a particular domain are generally permitted only by the registrant (or owner) of the domain.

Transfer of a domain should be initiated by a request to the agent by the registrant. If they have gone bust or causing trouble, you can approach the registry itself. They will not release the domain if you have signed a contract with the agent requiring you to pay a release fee.

The nameserver can be anywhere on the net. It is simply a machine that handles domain name lookups, translating them to the numeric, lower-level IP address necessary for transport over TCP/IP. The nameserver holds a "zone file" for the domain, and this file contains the mappings for various uses of the domain - the location of the web or mail server, amongst others.

Only the administrators of the nameserver can (directly) make changes to the zone file. They will generally only respond to the person identified as the technical contact for the domain, although in some cases these changes can be made online by the user, identifying themselves with a password.

Some issues to consider about the DNS world

Does the registry charge for transferral of your domain to another agent? - If considering changing to a new registry, does it charge for transferring in a domain name? Read the small print before proceeding! Some companies will charge £25 per domain name for transferring.
Are you stated as the domain owner on the domain registration? - Try to keep all your domains with one agent. Agents generally deal in all the main domains, so you shouldn't have to have more than one agent.
Who is listed as the technical contact? - You should make sure this is someone within your organisation, not the registrars.

You can often get nameserver services from the registry you buy domains from. This can be handy, as it means you will be able to make all your adjustments, including zone-file settings, through one point of contact. Easyspace.co.uk, for example, have a great web-based account administration allowing you to easily alter DNS details, change nameservers, buy new domains and obtain other related services.

Web-based management systems are very common with agents and will give you a lot of control over the administration of the names you control. Other places can have there own tedious in-house procedures of faxing or mailing company letter-headed paper to make a change.

Most agents will automatically inform you when your registration is due to expire, giving you the option of letting it lapse or automatically renewing it.

Take care when completing the application with your personal details.The details of the owners and contacts for a domain are publicly viewable, so make sure you use suitable names, addresses and email addresses. Make sure you keep these details up to date.

You can make a "WHOIS" search at most agents, this will allow you to look up the registration details for a domain. If you search with an agent who is not responsible for the domain, you may receive a reduced set of information. You will then have to locate the site of the agent (registrar) for the domain and make the WHOIS search again.

Generally the advice above applies to the TLDs and the ".uk" group of domains. If you are using other ccTLDs be sure to check carefully their terms and conditions. ".uk" is unusual amongst ccTLDs in that it allows registrations from non-UK residents, for example, and many other differences may exist between other ccTLDs.

Unfortunately NOF are unable to give you any direct recommendations of agents, however we do recommend that you take some time to read around the nominet (nic.uk) and ICANN sites to give yourself more background information. It is a murky area of the internet and many companies have pursued this to wring out extra money from their registrants : be sure to read the terms and conditions carefully and consider the advice given above.

Should you register the site with more than one TLD?

Each domain you register will incur an ongoing cost to your organisation for renewals, redirection and alias issues of different domains. The purpose of multiple registrations is to protect your name and to try to cover misspellings of your name and to prevent competitors from bagging domains that might siphon legitimate users of your site. More a concern for commercial organisations. However, having multiple domains makes your system administration more complex. Suppose your main domain is www.abc.com, and that site has a page called www.abc.com/search/. What will you do with a second domain www.abcd.com? will www.abcd.com/search be the same as www.abc.com/search, or will your users be redirected to the main domain first? This can cause problems...you have to decide a coherent strategy for this and you should discuss the options with the systems administration people carefully to avoid problems down the road. On the whole, people will reach your site either through a link, in which case the domain is, to the user, mostly irrelevant, or through printed publicity they receive, over which you have control!

Must I have a server set up and ready before I register a name or can I do it anytime?

....Anytime, you will just need to link the two together when your server is ready...this involves configuring the webserver so that is knows about the domains it is to serve, and changing the pointer (to the IP address of the web server) in the name server. For this reason, it is great to have control over your name server: either host it yourself, or use an organisation that gives you your own web-based administration of the nameserver configuration for your domains.

Remember:

registrar holds the look-up to the authorative name server
name server holds the look-up to the Web server

Often, the registrar will also host the name server for the domain, this is fine as long as you are still able to make changes to the config - ideally online.

Domains that you do register that do not have a live webserver ready for them should have a relevant holding page giving info about your project, a contact perhaps and if possible a means to capture email addresses to build up a user base asap. Again, this should guide your choice of registrar as they should give you a couple of free, editable pages that you can use as holding pages. Or set up a temporary web server for these purposes.

Don't forget that changes to name server settings will take up to 48 hours to be distributed around the net: it isn't an instantaneous change over the whole web. When a computer requests a DNS lookup, in order to find the IP address to send a URL, it will use it's local nameserver, and that server will keep a cached copy of the DNS info for that domain for a period known as the "time to live"...only once this has expired will the nameserver go back to the authoritive nameserver to refresh it's local copy of the record. (Keeps the traffic load on the net down, basically).

What suffix should we use?

There are no rules about the suffix (.com .org .co etc.) that you use for your NOF site but again as expense is an important factor it makes sense to use the most appropriate which is probably org.uk or co.uk. Some more information on the domain name you use is available on the NOF site at http://www.ukoln.ac.uk/nof/support/help/papers/website.htm#Domain.

12. To what degree must we provide support for web browsers, particularly where certain browsers, such as Netscape version 4 series, cause real difficulties when used on our website?

Quick Summary:

You do not have to support every browser in existence.
You must ensure that your pages validate against a published DTD.
You must test your pages against a representative combination of web browsers and operating systems.

Full Answer:

Netscape 4.x browsers, i.e. browsers in Netscape series 4, (e.g. Netscape 4.07, 4.08, 4.71, etc.) have very poor support for CSS and we are aware of the difficulties this can pose. However just as the difficulties posed by Netscape 4.x differ amongst those projects affected, so do their potential response to the problem; hence there is no definitive one-size-fits-all answer.

Action steps:

Ensure your webpages validate against the published DTD (Document Type Definition, aka DOCTYPE). Consistent, valid usage of HTML will greatly assist you in avoiding many problems.
As part of your wider user testing programme, create as comprehensive a list as practical of different computer operating systems, (e.g. Windows 2000, Mac OS 10, etc.) and browsers, (e.g. versions of Netscape, Internet Explorer, Opera, etc.). Systematically test against all these browsers/OS combinations.
(You might consider publishing a list of brower/OS combinations that you have successfully tested in an "about" section of your pages.)
Where problems are observed, you should in the first instance investigate the problem and attempt to resolve where possible.
If the effort required to fix the problem is too great, (which may indicate a need to write separate pages targeted at the problematic browser(s)), we recommend that you implement a strategy of detecting those users and directing them to a warning page.

The warning page should inform users of the problem and offer links to updated versions of browsers available for downloading. If you have a text-only version of the site, you may offer them that too, as an alternative.
As part of your normal monitoring strategy, you should be aware of the users of your website, including the browsers they are using and the proportion of the overall total who are using browsers that are giving difficulties. If a review of the results of your monitoring indicates that a significant proportion of your audience is using, say, Netscape 4.x browsers, then you need to consider devoting more time and effort to developing the means to meet that significant demand.

Further Reading:

Dive Into Accessibility Website
http://diveintoaccessibility.org/day_26_using_relative_font_sizes.html
Caio Chassot: Hiding CSS from Netscape 4
http://www.v2studio.com/k/css/n4hide/
CSS Layout Techniques: for Fun and Profit
http://www.glish.com/css/
To Hell with Bad Browsers
http://www.alistapart.com/stories/tohell/
CSS and Netscape 4.xx Issues
http://www.mako4css.com/csstwo.htm
DevEdge Website
http://devedge.netscape.com/
Browser News
http://www.upsdell.com/BrowserNews/

13. Can you detail some simple checks one can perform to ensure that my website is compliant with the technical standards?

Quick Summary:

There are two issues which we have noticed on a fairly regular basis and which usually require attention:

CHARACTER ENCODING
DOCTYPE DECLARATION
Full Answer:

CHARACTER ENCODING:

We would like to remind all projects that it is important that the character encoding used in a text document delivered over the web is clearly identified. Best practice is to identify the character encoding in use BOTH in the HTTP header and within the <head> section of the document.

Where XML/XHTML is used, it is also good practice to identify the encoding in the "<xml .." declaration at the start of the document.

Whilst the Technical Standard and Guidelines document currently mandates the use of UTF-8 encoding (setion 2.1.2), this is under revision and it is permissible to use any appropriate encoding (ie iso-8859-1, etc), as long as this is explicitly stated as discussed above. The TS&G will be updated at the end of this year to reflect this change, and at that time the section B of the quarterly monitoring reports will also be modified. In the meantime, please indicate the actual encoding your project is using when filling out your quarterly progress report.

Further Reading:

HTML Document Representation
http://www.w3.org/TR/REC-html40/charset.html
Character Encoding
http://www.w3.org/TR/xhtml1/#C_9
XHTML Media Types
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/

DOCTYPE DECLARATION:

We would also like to point out that it is necessary to include a DOCTYPE declaration at the top of all HTML or XHTML pages. This is necessary to allow your mark-up to be correctly validated, and perhaps more importantly can affect the way the user agent (browser) interprets the mark-up it finds within the page. Therefore, a DOCTYPE statement correctly identifying the version of (X)HTML that you are using on the page will improve the chances of your page rendering correctly across different browsers and clients. Please ensure that you include the DOCTYPE declaration on all your pages.

Further Reading:

HTML version information
http://www.w3.org/TR/REC-html40/struct/global.html#h-7.2
Document Conformance
http://www.w3.org/TR/xhtml1/#docconf

UKOLN is funded by MLA, the Museums, Libraries and Archives Council, the Joint Information Systems Committee (JISC) of the Higher and Further Education Funding Councils, as well as by project funding from the JISC and the European Union. UKOLN also receives support from the University of Bath where it is based.

T A S : 2 0 0 1 - 2 0 0 4 : A R C H I V E
This page is part of the NOF-digi technical support pages http://www.ukoln.ac.uk/nof/support/.
The Web site is no longer maintained and is hosted as an archive by UKOLN.
Page last updated on Monday, May 09, 2005