If you have a problem that isn't covered below then complete the feedback form on the main website to report it. Don't forget to leave a valid email address where you can be contacted.
Please ensure that you have the latest version of the tool installed.
You must have Java installed in order to run the tool. The tool requires Java Runtime Environment version 6.0 or higher. On Windows, if the tool cannot find a suitable version of Java when it tries to start you will be prompted to run your default browser and then taken to the official site where you can download and install the latest version.
With Linux installations You must have Java 6.0 or above installed and this must be in your PATH. Type 'java -version' at the command prompt to check this. Alternatively, make your own copy of the *.sh scripts in the installation folder and amend them to point to wherever you've installed Java.
If you have any other start up issue then make a note of any error messages that may appear and use the feedback form to report your problem. Don't forget to leave a valid email address where you can be contacted.
Depending on your settings, the OS X Gatekeeper may prevent you from running the tool the first time, saying that it is from an "unidentified developer", or "damaged".
Open the 'Applications' folder in Finder and proceed as follows:
- Right-click (Control-click) TotalValidator or TotalValidatorPro and choose "Open"
- At the next dialog warning click the "Open" button again
Once the tool has run the warning should no longer appear, although it may reappear if you download an update. See the OS X documentation for details of how to permanently turn off these warnings.
When the validation is finished your browser should start up and display the results. If this doesn't happen, first check that 'Hide results' in the Options menu has not been accidentally selected.
Otherwise try using the 'Last Results' button. If this doesn't work then (Pro tool only) check the browser you have selected on the Results tab; a blank entry implies using your default browser. If nothing else is obviously wrong then it's likely that you have a browser installed that is not set as the 'default'. You can correct this for popular browsers as follows:
Windows/Mac: If Firefox is your preferred browser then open it and go to the 'Tools' menu and select 'Options' then 'General' and you will find an option which allows you to set it as the default browser.
If Internet Explorer is your preferred browser then open it and go to the 'Tools' menu and select 'Internet Options' then 'Programs' and tick the box that says that IE should check to see if it is the default browser. Then restart IE and you will be prompted to confirm IE as your default browser. In either case then try running the Total Validator Tool again.
Linux: Edit the script 'totalvalidatorpro/default_browser.sh' or 'totalvalidatorbasic/default_browser.sh' as appropriate and check that it points to your preferred browser. As an additional check if you simply run this script without any parameters then your browser should just start up normally.
If you are still having problems then it may be that the results are stored somewhere inaccessible, and you may have to navigate to the folder where the results are stored and manually launch your browser pointing at the first results page.
This message appears when the tool cannot connect to the starting web page. So ensure that you can connect using the exact same URL in your browser first.
If you can see the page with your browser, it may be that there are one or more proxy servers between you and the page, or the page requires authentication to view it. Unfortunately, if you are using the Basic tool there are no options available to allow you to authenticate yourself or to specify a proxy server, although you could use a browser extension to validate the source code of the page. Pro tool users should look to the options on the Authentication tab for further information.
If you are using the Pro tool and you still can't authenticate yourself or drill through a proxy server, then then complete the feedback form on the main website to report your issue.
So that you can validate just a portion of your site, by default the tool will only follow links that begin with the same URL as the starting page's folder. For example if your starting page is 'http://www.mysite.com/some_path/index.html' then only links that resolve to URLs that begin with 'http://www.mysite.com/some_path/' will be validated.
By default, pages on 'http://mysite.com' will not be validated because technically-speaking 'http://mysite.com' and 'http://www.mysite.com' could host completely different websites.
Similarly, pages beginning 'http://www.mysite.com/Some_Path/' will also be ignored because paths in URLs are case-sensitive. If you are running a server on Windows, and in particular using IIS, then your site may still appear to work despite this error. In this case see the ignore case option for more information.
If you need to validate other parts of your site (or other sites) from your starting page, then see the options on the include tab which can be used to override the defaults. The next section may be of use as well.
If you believe that the reason why so few pages are being validated is because the tool is not logging into a form correctly, then see the section on Login forms. The next section may be of use as well.
A common requirement is to validate disconnected parts of your website and/or other pages linked to your starting page as the normal way the tool works prevents this.
You can change this behaviour using the Follow local and Follow remote options. The Follow local option tells the validation engine to follow any page on your local website no matter what the starting page.
The Follow remote option tells the validation engine to follow all links on the starting page only even those on different websites. Although this option can be used with an existing web page, it is usual to create a new, simple web page consisting of absolute links to the various parts of your site, or listing different sites. This page may be saved to the local filesystem (i.e. no need to deploy it to a website). Then use this page as the starting page with the Follow remote option. The validation engine will then treat each link (on this first page only) as if was the starting page.
There could be several reasons why the tool may appear to operate slowly when checking each page. Obviously it could be that your system has reached the limit of its own performance in terms of CPU power and/or the amount of available memory. However there are several things you can try to improve matters as listed below:
- The broken links option waits for a response from remote sites. If you do have any broken links then this will naturally slow down the tool. With the Pro tool you can reduce the timeout from the default of 20 seconds and raise the concurrency (or set to 0 for unlimited). Alternatively turn off the broken link check altogether.
- The spell check has a double impact on performance. It uses a lot of memory loading the dictionary, and it can take time to spell check each word. So try turning this option off to see if this helps.
- Try to limit the number of other applications that are running concurrently
- When checking remote pages close any other applications that may be using the network
If none of the above work and you have sufficient memory then you could try increasing the amount of memory used by the tool.
Unlike many popular validation services (such as HTML Tidy) Total Validator uses the official W3C and ISO DTDs for HTML validation and the tests are automated from these. In other words we haven't personally made up the validation rules or translated them. So if Total Validator finds a problem on your page (or fails to find one) then it's highly likely that it's in the W3C DTD's and not a mistake in Total Validator.
Many other validators do not use the official DTDs but are interpretations of them. The most popular example is HTML Tidy. Because these do not use the official DTDs they tend to be rife with mistakes. HTML Tidy for example reports the 'type' attribute in the <link> element as being mandatory. This is both wrong and often doesn't even make any sense.
However, the official DTD's cannot encode all the rules, because of the limitations of the DTD language. So we've added a whole lot of additional tests to cover these limitations. So other validators that only use the official DTDs may miss errors that are there in the standards. For example the W3C validator doesn't check the value of attributes and so will report success even when your page has many mistakes.
So before you report that another validator says that your page is okay, or reports errors that Total Validator doesn't pick up, please check the actual standards first, don't just assume the other validator is right. Note that we wrote Total Validator initially because of mistakes and limitations with other popular validators.
Remember that the accessibility standards are guidelines and not rules. They can't possibly cover every situation and are there to guide you into making good decisions.
To properly check a page for accessibility you need to understand the standard you are applying and manually look at the source and the output of the page. Automated validators (even Total Validator) can only guide you and should never be regarded as a stamp of approval. Never let zero errors and warnings be your only target and bear in mind that it is quite easy to write a web page that passes all the tests of all the validators and yet would still be difficult for people with disabilities to use. Equally, errors and warnings in validators are just there to alert you as to potential problems, and so may appear when there is actually no problem at all.
So we recommend that you check your pages against the guidelines manually ensure they meet your accessibility requirements and only then use Total Validator to check for anything you may have missed or after making minor amendments.
With Total Validator we've tried to follow the spirit and meaning of the WAI and Section 508 guidelines, rather than blindly coding rules. So you may find many 'warnings' and 'notes' reported by other validators that simply don't appear in our results. Before you put pen to paper to berate us, check out the guidelines themselves first, as these reported items may be false positives, and not apply to the page in question at all.
Some specific things of note: User-agents are much better than they were when the WAI guidelines were first written. As a result many of the WCAG 1.0 guidelines are now redundant. For example there is no longer a requirement to put place holding text in edit boxes and text areas. This was 10.4 of WCAG 1.0 (AAA). Similarly 1.5 of WCAG 1.0 (AAA) is no longer required. So always validate using the latest version of Total Validator.
Many error messages are self explanatory and should help you to correct the problem is yourself.
If you have a message that doesn't make sense then make a note of it and complete the feedback form on the main website to report your problem. Don't forget to leave a valid email address where you can be contacted.