{"id":42,"date":"2004-11-08T02:55:59","date_gmt":"2004-11-08T02:55:59","guid":{"rendered":"http:\/\/lachy.id.au\/log\/2004\/11\/iinet-standards-redesign"},"modified":"2006-04-30T23:51:47","modified_gmt":"2006-04-30T23:51:47","slug":"iinet-standards-redesign","status":"publish","type":"post","link":"https:\/\/lachy.id.au\/log\/2004\/11\/iinet-standards-redesign","title":{"rendered":"iiNet Standards Redesign"},"content":{"rendered":"

Recently, and to my surprise, iiNet<\/a> have redesigned their entire site. Not only that, but it validates as XHTML 1.0 Transitional<\/a>, separates presentation from structure (no tables for layout!<\/strong>), makes reasonably good use of alt text (it\u2019s not perfect, but it\u2019s quite good), fairly accessible use of JavaScript (no serious problems caused with it disabled) and even makes good<\/em> use of sIFR<\/abbr><\/a>!<\/p>\r\n\r\n

iiNet have discussed this re-branding<\/a> from a marketing perspective. That\u2019s fair enough, a typical customer isn\u2019t going to want to hear about their new found standards compliant and accessible design methods. So, in the process of congratulating them for this fine effort, I\u2019ll take a look at exactly what they have done.<\/p>\r\n\r\n

Structure and Presentation<\/h5>\r\n

Disabling stylesheets quickly reveals that they have actually put in a lot of effort into this redesign from the previous. The old design was a typical table layout with spacer gifs, invalid markup and a few pages just didn\u2019t work correctly in anything but IE. With the redesign, they\u2019ve used reasonably semantic markup \u2013 headings use <hn<\/var>><\/code> elements, paragraphs use <p><\/code>, navigation menus and other lists use <li><\/code> and there\u2019s no use of presentational class<\/code> names or id<\/code>s.<\/p>\r\n\r\n

They have, unfortunately, used a few style<\/code> attributes, but not many. Most of the presentation is specified in an external stylesheet. Ideally, they would use a semantic class name on those few elements that currently use the style<\/code> attribute, but the damage caused is minimal<\/p>\r\n\r\n

As I mentioned earlier, the markup does validate as XHTML 1.0 Transitional, with the exception of one image missing an alt<\/code> attribute on this page discussing their re-branding<\/a>. However, it is a presentational image, and only requires an empty alt=\"\"<\/code> attribute anyway. The home page nearly validate as Strict, however the only errors seem to be structural, due to <input><\/code> elements being directly inside a <form><\/code> element, the use of a name<\/code> attribute in a <form><\/code> element and the use of a target<\/code> attribute, which I strongly discourage<\/a>. They\u2019ve also used an invalid value: target=\"_new\"<\/code>. The HTML 4.01 Specification<\/cite><\/a> states:<\/p>\r\n\r\n

Except for the reserved names listed below, frame target names (%FrameTarget; in the DTD) must begin with an alphabetic character (a-zA-Z). User agents should ignore all other target names.<\/p><\/blockquote>\r\n\r\n

This means, that except for the special defined values, _blank<\/code>, _self<\/code>, _parent<\/code> and _top<\/code>, the value must begin with an alphabetic character. Thus, _new<\/code> is invalid, even though the validator does not detect it. But, you must keep in mind that the validator is just a tool<\/a>, and cannot check every conformance requirement, only those specifiable with the DTD<\/abbr>. So, technically, they should be using _blank<\/code>, but ideally, they should remove the target attribute completely, since the user<\/em> should decide when they want a new window, not the author.<\/p>\r\n\r\n\r\n

XHTML vs HTML Markup<\/h5>\r\n

Update:<\/strong> One thing I forgot to mention earlier, and hence why I\u2019m adding this update, is that technically, they should not be using XHTML since they are serving it as text\/html<\/code>, and doing so is considered harmful<\/a>. If they\u2019re going to use XHTML, they should be using content negotiation to deliver it correctly as application\/xhtml+xml<\/code> to descent UAs<\/abbr> that support it, and text\/html<\/code> to IE, and other legacy UAs that don\u2019t. However, as many of you will know, this issue has been discussed recently. Some say it\u2019s OK<\/a>, other\u2019s (like myself) think it should be avoided, and other\u2019s insist that it should not be done<\/a>. These people categorised into either the Stict or Transitional Party<\/a>.<\/p>\r\n\r\n

If they\u2019re not going to serve XHTML properly, then they may as well use HTML 4.01 Strict. I recommend they change to Strict, because Transitional actually triggers Almost Standards Mode<\/a> in Mozilla. It is near enough to standards compliance, but it adds a small quirk that should not be there, and only exists to support the thousands of pages that depend on IE\u2019s bugginess, yet still use a valid DOCTYPE.<\/p>\r\n<\/ins>\r\n\r\n

Images and Alt Text<\/h5>\r\n

As mentioned, there is one image that I found without alt text, but other than that, they seem to have actually done a reasonable job. Although, ideally, (in this case) the images should have exactly the same text as the images do, however, they have used text with a similar meaning, and viewing without images doesn\u2019t loose too much.<\/p>\r\n\r\n

For example, one image they have at the moment, states christmas broadband specials. Free Setup + Modem. Save up to $199.95<\/q>. However, they have set alt=\"christmas special - free setup\/modem\"<\/code>. It misses the price, but it still passes a message that is close enough, especially compared with the vast majority of sites that use very poor, or no alt text whatsoever.<\/p>\r\n\r\n

They have made use of Image replacement techniques for the navigation items, though not in the most accessible way. However, that\u2019s limitation with CSS and image replacement techniques<\/a> in general. iiNet have done image replacement by setting the background image on the <a><\/code> element for each link, so that hover effects still work in IE, and set the font to 1px, white to effectively hide it from view. However, like many image replacement techniqes, this is inneffective in the rare case that images are disabled, but CSS is enabled.<\/p>\r\n\r\n

For many the headings, they have made use of sIFR<\/abbr><\/a>, which was designed and developed to be accessible in the majority of cases. It has known limitations, but so far, is the most accessible image replacement technique available.<\/p>\r\n\r\n

JavaScript<\/h5>\r\n

The site does make some use of JavaScript, however the site does not require it. With JavaScript disabled, the only issue I found was that the what\u2019s webmail<\/q> and what\u2019s toolbox<\/q> links don\u2019t work. They are JavaScript links with the purpose of showing additional information about the webmail and toolbox services. Ideally, with JavaScript disabled, that information should be visible by default, but the additional information is not that much, and can be obtained by disabling stylesheets also. The links should also be added using JavaScript, so that useless links do not appear for users with JavaScript and\/or CSS disabled, but again, it\u2019s a minor issue.<\/p>\r\n\r\n

So, in conclusion, I would like to congratulate iiNet for taking the initiative to move towards standards compliance, and for actually hiring a web developer that knows what they\u2019re doing. Well Done!<\/p>","protected":false},"excerpt":{"rendered":"Recently, and to my surprise, iiNet have redesigned their entire site. Not only that, but it validates as XHTML 1.0 Transitional, separates presentation from structure (no tables for layout!), makes reasonably good use of alt text (it\u2019s not perfect, but it\u2019s quite good), fairly accessible use of JavaScript (no serious problems caused with it disabled) … Continue reading iiNet Standards Redesign<\/span> →<\/span><\/a>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[5,2,7,3],"tags":[],"_links":{"self":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/42"}],"collection":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/comments?post=42"}],"version-history":[{"count":0,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/42\/revisions"}],"wp:attachment":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/media?parent=42"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/categories?post=42"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/tags?post=42"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}