Hints and Tips for Entrants
We know just how much blood, sweat and tears go into creating a successful web project, and the last thing you need is to jump through hoops to get your site submitted.
To make this as easy as possible we have build up a set of hints and tips that should make the entry process a little bit smoother.
Let the Robots In!
In order for sites to pass the judging in round one they must grant access to our performance, accessibility and validation bots! Also websites that have robot exclusion texts (which link checkers are a type of) will also not be eligible for judging.
It takes a fair amount of time to validate websites; it is just not the home page. It is often up to five pages and when the bots can’t do there job it adds time to the process. So let them in from the end of July to September.
Validate
There are some fantastic tools out there that allow you to make validation part of your workflow, and if you don’t use them yet, go and check them out. These are the sites and software that we will use when validating your entry, so we suggest that you run your sites through these before you enter:
- Total Validator extension for Firefox – This is used as it checks links, mark-up, WAI Priorities, and provides a screenshot of pages validated. Settings used are below:
- Validation TAB – Validations to perform: HTML, Accessibility, Broken Links, Take a screen shot; Other settings – Online Service, Report warning as well as errors, Show on Success
- HTML TAB – Auto Detect. Any HTML or XHTML
- Links – leave as default.
- Screen Shot – Choose Windows version, with browser determined to be audience preferred.
- Accessibility – WCAG Priority 1 & 2. (NOTE: This result is used later on in the judging process, and isn’t part of the pre-selection)
- CSS Validator @ W3C – This is the CSS validation page with more options and the options will be set to CSS 3 for normal projects and Mobile for mobile sites.
- Use of Browsercam to see the entered site in various browsers and platforms. Australian Web Industry Association has 5 rotating accounts that can be used by its members, however if you cannot afford a Browsercam account or are not a member of the Australian Web Industry Association, there is browsershots, which is a free open-source alternative.
- Use of Mobile device simulators to check websites in mobile devices.
But my client broke my code!
We feel your pain. Mind you, if clients understood how to produce good HTML, they wouldn’t need us, would they? We only intend to judge the work that YOU do, if the client has decided to go against your advice and cut-and-paste large sections of Word Documents or dropped in a blown up animated spinning email logo, then we won’t penalise you for that. (Although, you might want to offer to fix it up for them, no body needs to see that sort of thing). If you want to make our lives just that little bit easier, drop in a couple of comments denoting where the user-generated content is, so we can work around it.
Google Adwords’ markup sucks
You would think Google would know better. Again, if you are using third party widgets or online advertisements that automatically drop code into you site, we aren’t going to penalise you for that either. An example of stuff we’ll quietly ignore is You Tube videos (Well videos in general), widgets and online syndicated advertising. Again, remember we are judging what YOU do.
Oh, come on – it’s just an ampersand!
A warning is a warning though, and three of them means you’re out. So double check you have escaped any special characters (the ampersand is a killer) and make sure you add “alt” attributes to image tags, and terminate any single (empty) tags correctly (obviously only relevant for XHTML).
Errors in previous years have mainly been from use of deprecated tags and properties in HTML 4.01 as well as the following errors in XHTML 1.0:
- parsing errors (usually un-escaped ampersands or special programming characters)
- not adhering to standards for empty tags,
- using a mix of HTML 4.01 and xHTML tags and properties
- using properties for tags that are not in the standard, and
- using JavaScript events/methods not allowed in the standard
If in doubt, see what the validator says.
But there is no other way!
Whilst the great browser wars of the dark ages did eventually give us some decent browsers to work with, there are still a few things that cannot be done cross-browser without bending the rules a little. Things like adding erroneous (but VALID!) mark-up to include those groovy rounded corners will be ok, as will adding a start attribute to a ordered list that needs to continue on after a paragraph (It’s not valid in XHTML, but there the only valid solution is to use CSS properties that half the browsers don’t support). But if we can come up with a decent way to do what you have hacked, watch out! If in doubt, ask the committee brains trust.
CSS Validation
Same rules apply. A sneaky tip here – the automated validation tools we use won’t pick up a correctly implemented IE conditional stylesheet (You know, the ones that look like comments to every other browser), and as far as we’re concerned, they are valid. In a perfect world, you wouldn’t need them, but we understand that it’s 4am and the site needs to go live and IE has been misbehaving…
CSS3 and HTML5 Validation
If you are using CSS3 rules and HTML5 tags, great! They will not invalidate you entry, as long as you have the right syntax, and we will check.
We will validate for CSS3 or HTML5. Also ensure the site degrades well in the less clever browsers, we check this too.
Accessibility
There has been great debate about the validity of the WAI automated accessibility validation tools for WCAG1. However the tools for WCAG2 are a vast improvement.
With this in mind we are now making accessibility a component of the first round of judging. We believe best practice should now involve a component of inclusive (accessible) design.