Archive for June, 2005

Announcements

Sunday, June 19th, 2005

New Job

Last week, I was finally offered a full time job as a web developer/designer with one of the best web development companies I’ve found in Australia. HotHouse Interactive have a strong focus on standards compliance and accessibility; and, although their own homepage is ill-formed XHTML served as text/html with a few other mistakes, they do a reasonably good job of seperating the presentation from the structure and content with relatively semantic markup.

My first impressions, after having worked there as part of a contract role for the last 3 weeks, have been very positive. I’m sure I’ll learn a lot from working there and I believe they’ll also learn a lot from me, now that I’ve become permanent.

Hosting Plan

It seems the traffic to my site has steadily increased over the last few months. I exceeded my 3GB bandwidth limit on the final day of last month and I was getting very close to going over again this month, so I decided to upgrade my plan. I now have 10GB of bandwidth, which should suit me well for quite a while.

I had been putting off upgrading previously due to financial contraints, but now that I have a full time job I should be able to afford a lot more. It has been suggested to me in the past that I consider using advertisements to help pay for this site, but my current feeling is that I hate advertisements and to do so would be hypocritical of me. I may one day consider other alternatives, such as accepting donations, but at this stage, I have no plans for that.

Media Attribute Accessibility

Monday, June 13th, 2005

Recently, Anne van Kesteren demonstrated a nice technique with the XHTML 2.0 media attribute designed to deliver a contact form to screen users, while giving a postal address for print users. Faruk Ates also published an interesting article about XHTML 2.0 and Google, specifically focussing on the potential abuse of the media attribute to hide content from screen users, but not from Google. However, this got me thinking about some of the accessibility issues involved with this technique.

Take a look at Anne’s example:

<section>
  <h>Contact</h>
  <div media="screen">
    Contact form to be inserted here.
  </div>
  <div media="print">
    <address layout="relevant">Anne van Kesteren
    Crosestijn 4629 …</address>
  </div>
</section>

As you can see, this clearly provides suitable alternate content for users depending on whether they’re using a screen medium, or print medium. However, what about other media types like braille, embossed, handheld, projection, speech, tty, tv or any other media? They get nothing!

Clearly, the intention of this example is that the contact form is not suitable for any static media (embossed and print), while the postal address is. There is also no reason why a postal address isn’t suitable for all media. One solution, and currently the only usable solution, is to explicitly list all suitable media in the attribute (it’s a comma separated list). However, what happens when CSS extends the list of possible media in the future? Would the media attributes then need to be updated to reflect this?

Another solution I can think of would be to allow for the CSS media groups to be used instead, but AFAICT, that’s not possible at this stage. For example, the above example could become:

<section>
  <h>Contact</h>
  <div media="interactive">
    Contact form to be inserted here.
  </div>
  <div media="all">
    <address layout="relevant">Anne van Kesteren
    Crosestijn 4629 …</address>
  </div>
</section>