Lately we’ve been working on a lot of content heavy websites here at UV^d, all of which follow the very common hierarchical structure (or taxonomy) of the web: categorised sections, which contain articles of content that are all related to that category.

When we are faced with the problem of having to show a way of navigating this hierarchical structure within our HTML it’s very common practice within our industry to use a breadcrumb pattern of markup. The most common of which up until recently has been to use an un-ordered list element <ul> and the navigation links to be list-items within the list, example of which can be seen here:

<ul>
	<li><a href=”index.html” title=”Home”>Home</a</li>
	<li><a href=”products.html” title=”Products”>Products</a</li>
	<li><a href=“shoes.html” title=”Shoes”>Shoes</a></li>
</ul>

Chris Coyier of CSS-Tricks recently wrote an article on the issues surrounding this age old pattern titled “Exploring Markup for Breadcrumbs“, and suggested some markup solutions to tackle it. As Chris stated the use of a <ul> is

“semantically wrong putting each navigation item on the same hierarchical level.”

The final solution he suggests uses the HTML5 <nav> element to wrap the items, which satisfies our semantic goodness needs denoting that everything contained within it should be treated as a navigation structure, and then uses the rel attribute and the up to indicate the hierarchy on each level:

<nav>
 <p>
  <a href="/" rel="index up up up">Main</a> >
  <a href="/products/" rel="up up">Products</a> >
  <a href="/products/dishwashers/" rel="up">Dishwashers</a> >
  <a>Second hand</a>
 </p>
</nav>

Although this solution is now semantically correct and the rel attribute allows each item’s level to become machine-readable there was something that still bugged me about it, it’s accessibility towards users using assistive devices or screen reading based browsers. The up value is still in debate by the spec editors and isn’t likely to be supported in any screen readers for a long time. After a lot of experimenting and some in-depth discussions with a fellow frontend dev friend of mine Dan Claydon and a sprinkling of ARIA I’ve come to this solution:

<nav role="navigation">
<p id="breadcrumblabel”>You are here:</p>
<ol id="breadcrumb" aria-labelledby="breadcrumblabel">
<li><a href="index.html" title="Home">Home</a></li>
		<li><a href="products.html" title="Products">Products</a></li>
		<li><a href="shoes.html">Shoes</a></li>
	</ol>
</nav>

The advantages of this pattern are:

• The use of the WAI-ARIA aria-labelledby attribute to instruct the user agent to use the label inside the <p> element to label the content of the navigation list
• Semantics: using the <nav> and <ol> elements to create a much cleaner structure to both machines and humans
• Separation of structure and aesthetics. You can use the CSS2 :after pseudo attribute to place the visual > separators after the links. As I am a strong believer that they do not belong in the markup
• You can chose to either hide the label off screen using css (which I have) or leave it if it fits your design and acts as a strong visual clue to everyuser
  Although a more accessible pattern it still brings some issues along with it. The elephant in the corner and its lack of support for HTML5 elements and CSS2-3 attributes (IE 6-8). Unfortunately the only way around this is to use some of the very clever javascript “polyfills” that are popping up all over the web at the moment. Two of our favorites here at UV^d , perfect for this pattern are: Modernizr and Selectivizr
• Modernizr allows you to use advanced feature detection on the clients user agent for progressive enchancement, and also uses a great HTML5 element polyfill which will allow us to style our <nav> element
• Selectivizr combined with your framework of choice (jQuery in our case) allows you to use some of the more recent CSS2-3 selectors in your stylesheets and parses them for the older browsers. Thus allowing us to use the :after pseudo selector for our navigation items

I would love to hear your feedback regarding this pattern and if you have any other techniques to improve the solution, and of course would like to credit Chris and Dan who gave me the inspiration. Below is a list of some further reading around the ARIA spec and accessible forms of navigation.

• ARIA Relationship attributes (i.e. labelled-by)
• ARIA ‘navigation’ role attribute
• An accessible pagination pattern

Patrick has been working on our most recent web design project and we’ve now had sign off on the new homepage so though we would share a sneak preview of the work. The project is for Felton Fleet, a mixed independent school near Cobham, Surrey. It is being designed in conjunction with a mobile friendly version utilising CSS3 Media Queries which Patrick also blogged in Going Mobile with CSS3 Media Queries.

Click the image above to see the preview.

You must either live in the Outer Hebrides or have been asleep for the last year not to have heard about the HTML 5 and CSS3 buzz bouncing around the interwebs: every developer or wannabe marketing exec is trying to get in on this particular piece of the pie. Therefore, we thought we’d give you a little insight into one of our favourite CSS3 modules ‘Media queries’ and how we are using it to make websites more mobile friendly.

Firstly let’s get one thing clear, contrary to popular belief CSS3 is NOT part of HTML5, it’s a completely different spec written and managed by a completely different group of people. But, much like HTML5 it is made up of multiple modules each addressing new functionality to the CSS base spec.

Although only getting a lot of attention recently, the Media queries module has existed since 2001 (yupp 9 years old!) but due to a gradual influx of capable media devices and user agents (iPhone, Android, Safari, Chrome e.t.c) they have only recently become useful.

So what are they, and how can they help me I here you ask?! Media queries are simply logical expressions that enable you to declare style declarations specific to a media device or type. Between the various HTML and CSS specs there are eleven different media types:

"all", "aural", "braille", "embossed", "handheld", "print", "projection", "screen", "speech", "tty", "tv"

We have seen media types being used for years, for instance using “print” style sheets to change a documents layout specifically for printing. Media queries extend this functionality further allowing us to specify exact aspects or “features” of a device, thus enabling very specific style declarations based upon whether features exist on the target device or user agent. These features are:

Width, height, device-width, device-height, orientation, aspect-ratio, device-aspect-ratio, color, color-index, monochrome, resolution, scan and grid.

Therefore, a media query consists of a media type and zero or more expressions that check for the conditions of particular media features, as shown in the example syntax below.

This specific query would apply to all screen devices with a maximum screen width of 480px, which is in fact one of the queries we are using on this blog to aid the experience on more advanced mobile devices and smart phones such as the iPhone (as 480px), but you can still see these style changes now if you reduce your browser to a width below 480px.

You can now see the amazing potential of media queries in the mobile world, we can define specific styles based on the devices resolution, colour or screen size, and as it is CSS the styles will cascade down. Therefore, you can have a set of styles for all devices, which will cascade down through all of the other queries. This allows you to deliver the same content to every device, which adapts based on the devices capabilities. This makes your website pages much more future proof as we are testing for features on the device or user-agent rather than sniffing for browser versions like we had to do in the past.

We have been getting very excited at UV^d recently surrounding the massive change we are seeing in the mobile world and have been gearing our own as well as our client’s websites to be ready and take full advantage of all the new functionalities to play with. I hope this post has given you a little insight into what you can do with media queries and encourage you to go and give them a try for yourself! I have also included a list of great further reading below.

http://www.slideshare.net/maxdesign/css3-media-queries
http://www.alistapart.com/articles/responsive-web-design/
http://dev.opera.com/articles/view/the-mobile-web-optimization-guide/

For those of you who are not familiar ARIA (or “Accessible Rich Internet Applications”) is a way further conveying a specific elements role within a webpage or application through the use of enhanced semantics. This allows for screen readers and assistive technologies to more accurately define to the user how to interact with a websites controls, in turn creating a richer user experience. It is especially useful to define the use of more advanced user interface controls (that are becoming increasingly more popular ) made using javascript and ajax, that have states that constantly change.

For the more interested developers out there, ARIA is applied to your applications by placing extra attributes within your elements tags, most commonly using the role=”" attribute.  One of the most important aspects of ARIA is the ability to apply multiple attributes to an element (as you would do with ID’s or Classes). This is because each element can have multiple properties:

• It’s Role: role=”menu”
• It’s State: aria-disabled=”true”>

• It’s Properties: aria-haspopup=”true”

A simpler way of describing this may be to show you an example of the markup one would use of a simple two panel tabbed interface.

<ul role="tablist">
       <li role="presentation"><a href="" role="tab">Tab 1</a></li>
       <li role="presentation"><a href="" role="tab">Tab 2</a></li>
<ul>

<div role="tabpanel">
       <p>Content</p>
</div>

<div role="tabpanel">
       <p>Content</p>
</div>

Although this is clear when visually displayed like that, the only true way of showing ARIA in use is to see (and more importantly hear) it working within a supported browser or screen reader. Though, as with all new or unfinished W3C specs, browser support and implementation varies across all vendors, with JAWS and Window-Eyes supporting the most amount of roles and states attributes. This leads us to the question of ‘is it worth all the hassle?’, my own personal answer: YES, being a big supporter of progressive enhancement, as long as it aids a better user experience for some of your users then it is worth the small amount of extra time to implement it.

Overall, Todd’s talk was very insightful and good to see how Yahoo! are going about creating much richer user experiences for people with specific needs, and even more so educating others about the best practices which can hopefully lead to a more accessible web!

I will certainly be trying to force and implement the use of ARIA in future projects here at UV^d, so keep your eye out for more info and posts around the subject in the near future. Though in the mean time I have included some further reading to feed your ARIA thirst, and start trying out ARIA yourself. But as Todd said himself:

Reading the documentation only gets you so far.

So try actually testing your new aria goodness with a screen reader, two of the links below are to help your setup a screen reader testing environment on your machine.

Enjoy!

Further reading:
WAI-ARIA Best Practices

YUI Configuring screen readers

How to use NVDA and Firefox to test your web pages for accessibility

‘Conformance to these Guidelines will help make the Web more accessible to users with disabilities and will benefit all users.’

The site contains quite a bit of complexity and rich content and we have also built an interactive Flash component in AS3 for part of the site which requires alternative content.

We like to think we are pretty good at CSS and have built the site with all the pre-requisites. The only trouble is that when it came to releasing a test version of the site to the client, he was using Internet Explorer 6 (at the time of posting this accounts for 25% of all web browsers so not to be ignored).

We have spent the day painstakingly going through the site page by page to make it look and function just as it does in Internet Explorer 7, Firefox (of course) and Safari.

This got us thinking about starting a campaign: “One World, One Browser”

(and of course let it be Firefox*)

You may well say that this is dictatorial, anti-competitive, unimaginative even. But after tonight, who cares.

JOIN US. WE ARE ONE.

PS: More info on Accessibility on W3C here

*nb: update; I’m told now let it be Chrome.