The way people are using and accessing websites is changing. This is due to users having more diverse browsing experiences on a multitude of devices, including desktop browsers, smartphones, tablets and more. This creates challenges for web producers regarding how we should design for different screen sizes, resolutions and types of interaction (e.g. touch). More than that, it calls into question what it really means to design for the web today.

With new devices available, the one-size-fits-all approach to web design that we’ve stuck with for so long is no longer relevant. It’s now essential that the designs that we create are responsive to the different ways that users access our content. This document is intended to outline a process called ‘responsive web design and enhancement’ that can be used to optimise your website’s content and adapt to different screen sizes and devices. Download the document here:

Responsive web design and small screen optimisation

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.

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.