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, so we want to make the entry process for your work as simple as possible. Unfortunately it is a little more involved than just emailing us a URL, so we have build up a set of hints and tips that should make the entry process a little bit smoother.
In 2008, we ramped up the requirements for document validation, as we saw this as an important part of our maturing industry. We want to make sure that we are promoting best practices in what we do, and as a result, all entries must pass a W3C validation test to be eligible for judging. 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 three or four pages and when links cannot be checked automatically it adds time to the process. We understand that you may not what robots to scour your site however for the validation period (Mid-July through to beginning of September) the validators need to be able to check your web project’s links automatically.
There are some fantastic tools out there that allow you to make validation part of your work flow, 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 errors will count as a Fail
- Links – leave as default. More than 3 broken links will count as a Fail
- 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 – Any errors will count as a Fail. More than 3 warnings will count as a Fail. 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. The valdiation process is semi-automated, however we do check the errors, and if we see CSS3 or HTML5 then we will manual check the code. If you are using these leading edge components then please let us know in your submission as well. Alsol ensure the site degrates 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, and it is actually possible to fail these tests and still have an accessible site, we aren’t going to make WAI priority 1 a validation requirement – we WILL however takes the results into account in the criteria section of the contest – if you have been paying attention to those best practices, you should be fine.
I didn’t start or re-launch my blog this year
We understand that not everyone has the resources to re-skin their blog every 12 months, so we are happy to turn a blind eye to this restriction for entries into the blog category – as long as you have been actively posting over the past twelve months. We will only consider content from the past twelve months in the judging. Oh, don’t forget that we consider a blog a personal web journal. Just running [Insert favourite blogging software here] isn’t enough, so if your “blog” is mainly media or press release driven, you might want to consider the Media category.
I hope that you have found the above informative and helpful for your submission this year. Good luck and we look forward to seeing you in October and November for the State Awards and November for the National Awards!
Helen Burgess
Judging Chairperson