In the first article in this series, Content before Design, I discussed the approach to take when building sites structured in accordance to their raw content as opposed to their presentation. In part 2, I’ll be looking at how to use semantic markup and which XHTML elements are best used for different types of content.

What is semantics?

I used to naively believe that semantic markup was just clean, well-formed HTML with divs and uls instead of tables. I thought it was a term I could throw at clients and such to look clever. But although semantic markup is so much more, it is in essence very simple. Semantic markup is that which conveys meaning and the purpose of the content it contains. So, headings should be correctly wrapped in <h*> tags, unordered lists in <ul> tags and so on.

Semantics is meaning.

Well, ‘that’s just plain common sense’ you may be thinking. And of course you’re right! But regardless, the majority of websites are built so solidly around their design as opposed to content – you’d be amazed how many times obvious lists are created in paragraphs with line-breaks instead of in individual <li> tags. Or take this very site for example – the header logo is simply an image, no <h1> tag – although it’s obviously the top level heading.

“I will be fixing this elementary issues on the next redesign, I feel it’s good for the purpose of writing such articles to be able to point out my own mistakes.”

Making meaning

HTML provides us with around 40 tags to markup different types of content. This may have been dandy 15 years ago, but in light of the web’s immense expansion and the superfluity of different forms of media and content websites present – 40 tags looks rather slim. The result of this is 2-fold, either:

• designers look to alternative methods, such as microformats, to help expand the capabilities of their markup.
• designers are forced to use irrelevant HTML tags to contain and present content they weren’t originally intended for.

So, in some cases it’s 1 step forward, but in others it’s practically 2 steps back.

The easiest way to write semantic markup is to build sites with a content-out approach, as discussed in part 1 of this series. By writing your XHTML in a logical content order – you will automatically create the correct elements to represent the content of your site instead of the design.

Why is this important?

Well, not to bore you with the old accessibility argument but let’s not forget that websites are, in their rawest forms, conveyors of content to the user. Sure, we use CSS to make them look darn pretty and then we pop in a bit of client-side scripting or Flash to make them sparkle – but there’s a large portion of your visitors that won’t reap the benefits of all that time spent in Photoshop and writing lines of funny symbols.

Writing meaningful markup helps to group different content types correctly. When styles are disabled, or when your site is being parsed by non-visual devices, this will help to keep everything together and in order. However, it also aids styling to no end, and can also make it easier to associate elements and content types with scripting to easily control the dynamic and visual effects of entire blocks of content without having to assign various classes and ids to every item.

In the following example I have changed my current footer navigation markup into semantic, meaningful HTML that can now be styled more easily than when each footer link was independent of every other:

What’s better about it?

• Firstly, I’ve removed the useless <div> and marked up the internal contents (the list of links) in an unordered list.
• I’ve then replaced the <div> id with a more meaningful <ul> id. This will mean some CSS amends to transpose the styles.
• Doing this gives me more stylistic control over the elements with less code, but also means that without styles, the content will still make sense.

Simple eh? That’s the point! Creating semantic markup shouldn’t be an exceptional skill, it really is just a combination of a good knowledge of HTML and common sense. The new footer markup above is actually easy to control with CSS and will now appear far more coherently when viewed without styles.

Using the correct elements

It’s important to consider carefully which elements to use when marking up content. This can reduce bloated code in files, make CSS styling easier, aid dynamic control, make it easier to aggregate data to different sites and apps, and most importantly ensure that the content makes sense when all styles and scripts are off.

A few examples of incorrect uses of HTML:

BAD:

<p>This is a paragraph of information.<br /><br />This is the second paragraph of even more information…</p>

GOOD:

<p>This is a pararaph of information.</p> <p>This is the second paragraph of even more information…</p>

Ok that’s fairly obvious. What about when incorrect elements are used for styling before the true nature of the content has been considered:

BAD:

<span>”Knowledge speaks, wisdom listens.”</span>
<br />
<strong>Jimi Hendrix</strong>

GOOD:

<blockquote>
<p>Knowledge speaks, wisdom listens.</p>
<p><cite>Jimi Hendrix</cite></p>
</blockquote>

And one more chunky example for good measure:

BAD:

<strong>PHOTOSHOP FOR BEGINNERS</strong>
<p>Photoshop is a design package by Adobe that allows you to create and manipulate images and photography. Some of things you can do with Photoshop include:
<br /><br />
<strong>Cropping, rotating and resizing images.</strong><br />
<strong>Changing the lighting, brightness, contrast, hue and saturation of images.</strong>
<strong>Create shapes and objects and apply gradients and shadows.</strong>

GOOD:

<h1>Photoshop for beginners</h1>
<p>Photoshop is a design package by Adobe that allows you to create and manipulate images and photography. Some of things you can do with Photoshop include:</p>
<ul>
<li>Cropping, rotating and resizing images.</li>
<li>Changing the lighting, brightness, contrast, hue and saturation of images.</li>
<li>Create shapes and objects and apply gradients and shadows.</li>
</ul>

Marking up with Microformats

Microformats are a set of open data format standards to help create and ease web content publishing and transferring. They are designed to more appropriately label groups of data, such as an address or business card information. They are an extension of XHTML that open up a lot of opportunities with only the slightest bit of code. No new languages to learn, no complex scripting.

Microformats extend the potential of the traditional 40 (or so) HTML elements such as blockquotes, paragraphs and lists and enable us to describe and markup our content in even greater detail. They also allow us to markup content so it can easily be aggregated by other sources through XML, RSS and other technologies.

Now unfortunately I’m going to stop there before I embark upon another tangent on Microformats. They are most certainly a subject for another day, considering I’ve recently got the bible on Microformats for Christmas and it’s going to take a while to get through. So for now, please pop over to the Microformats website for lots and lots of more information!

Take a step back

Well, that about covers that for now. In the past 2 articles we’ve looked at designing from the ground up. Considering content first before fancy graphics and snazzy AJAX and Flash and looking at how to markup our XHTML correctly and semantically. In the 3rd part in this series I’ll be entering the deep realms of progressive enhancement, but until then I’d like to hear your opinions and views, so feel free to comment away!

This is the first article in a 3-part series that looks at how we design and build websites from the base up, focusing on the raw data and content that needs to be accessible to everyone before considering design and progressive enhancements. In part 1 I’ll be discussing the content-out approach, why it’s important to order content sensibly with markup and how to do it so. Part 2 and 3 will look at semantic markup, microformats and how to write future-proof XHTML before finally discussing progressive enhancement and how it can be utilised to help ensure an enjoyable, appropriate user experience for all.

Content before design?

When I say ‘content before design’ I’m not saying start playing in TextMate or Dreamweaver before picking up a pencil and paper and building ideas and visuals with Photoshop. There are plenty of different methods people use and recommend to approach project development. Some designers find it easier or faster to use XHTML Prototyping or Agile development, however I would never consider writing a character of HTML before I had a solid design and a confident vision of the final product.

Content before design means that the structure of your markup is written in a way that logically makes sense if reading it without styles or any form of dynamic behaviour.

This may seem an obvious thing to do, but the fact is that most websites built today, regardless of whether they are valid, built with divs and have nice alt attributes on every image, are still structured in accordance to their design. A lot of the time this may not make a huge difference if the website design features elements in a sensible order, but often is the case that in the markup – headers will all over the place, menu lists and blockquotes may be thrown in the weirdest places, because that’s where they appear in the styled layout.

Stripping Redswish

What better an example to use to demonstrate my point than this very site. Of course you should practice what you preach but in my defence I built this layout before I learnt these techniques and methodologies.

When you view Redswish with no styles, as may be the case with screen readers or all manner of devices, you are presented with the following:

First we are presented with the search box, then a secondary navigation, the logo image, the subscribe image then the first post on the page. To view the site yourself with styles disabled, in Firefox go to View>Page Style>No Style. If you’re in Internet Explorer I offer you my sympathy.

If you carry on down, you’ll discover that the primary blog menu is almost at the bottom of the page. Well, what use is that to someone wishing to navigate your site? The reason the unstyled Redswish site is in such an illogical, unusable order is because I built the content and the presentation alongside each other. Thus, my XHTML markup is structured in the order in which visual elements appear on the page, as opposed to a sensible order of content.

The content-out approach

When building a website, you should work from the inside out. Focus on the stripped-down, bare-bones content displayed in headers, paragraphs, lists etc before building containing and structural elements around this content to style. CSS is incredibly powerful and manipulative and can almost always be used to position and style elements anywhere on the page, regardless of their position within the markup. The most popular and functional example of just how far CSS can be exploited to transform the same XHTML can be found at CSS Zen Garden.

However, don’t let this restrict you. There will still always be instances where an extra div or span may have to be used, or perhaps one element placed before another in order for them to be composed well into the design. CSS isn’t perfect, but by building from the content out you should be able to use as few divs and containing elements as possible, whilst still achieving the same end result.

Get in line

The diagram below shows the order in which different blocks of content are displayed in the current Redswish site when styles are disabled. The right diagram demonstrates a more sensible approach to the order of this content:

Some may disagree with this, and I probably would as well. But difficulty arises because there are often presentational factors and different information design priorities that overrule the order of the basic content.

For example, on the current site – the sidebar features categories, archives, a subscribe block,feeds and blog meta data. From a usabilty standpoint – categories and archives take a priority over the other elements because they’re necessary for site navigation and are primary page elements. However, for the sake of the design, they can’t be separated too much from the secondary elements (eg. feeds and blog meta-data) otherwise it would be nearly impossible to keep them together visually with CSS.

Sometimes the best bet is to find a happy medium, where you can still easily control your site’s visual layout with CSS whilst non-visual browsers, screen readers and such will still provide the user with a logical, easily navigable content structure.

Optimising content order

Writing your markup in a sensible order is not rocket science. WCAG guidlines dictate that “when content is organised logically it will be rendered in a meaningful order…” – this is regardless of stylesheets.

So, ensure that headers take precedence, that navigation is in the correct order and that the order of information is ordered based on logical order and priority. An example of restructuring some basic elements so they make sense, regardless of stylesheets and visual presentation:

Don’t replace tables with divs!

Building sites with a content-out approach should allow you to style your pages more organically. By creating structural blocks first, before including the raw content, you can sometimes default back to what is virtually a tabular layout. Div’s simply become table cells and try as you might, your HTML will still represent the presentational layout, not the optimal content order.

In the next part of this series I will look at semantic markup, HTML naming conventions and microformats, how these techniques can be employed to help create more sensible, meaningful content structure, and how this can benefit your user’s experiences.

UPDATE – Check out part 2 here >

I’m never happy with my current skill level, I never quite feel like I’ve reached a particular stage that I’m aiming for. Maybe it’s just me; maybe I’ll never quite be happy with myself. Maybe that’s a good thing… maybe not.

But one things for sure – I’m constantly improving and bettering myself as a designer and much more, which is a good feeling. To be able to look back over the past 6 months and observe what new skills I’ve learnt, bad habits I’ve dropped, speed, accuracy and imagination I’ve gained and generally concede that I have improved in more ways than one is pleasing.

So, I’d like to offer some tips and ideas that may help others help themselves more, hopefully provide some inspiration and educate. And I’d sure like to hear what you think, if you’ve got anything to add please comment.

When learning: Read, Meet, Talk, Listen, Teach

And further verbs. Although it sounds cliche and quite extreme, if you want to get ahead in your game (and this doesn’t particularly relate to web design), you have to eat, sleep and breath design. Make contacts wherever possible, let people know what you do – you never know when it might come around and help you.

Reading

Resources for web designers are hardly scarce. Get subscribing to RSS feeds, get a good selection of favourite sites with regular news and tutorials and visit them regularly. I make an effort to spend a good 30-40 minutes (more if I get to the office early) every morning checking my feeds and bookmarking new sites full of inspiration.

Then don’t forget the print world, there are still a fantastic number of great quality web design, development, graphic design, copywriting and project management books popping up all the time. Hit up Amazon and see what tickles your fancy. Then don’t let them gather dust on a shelf – have them open on your desk, read on the train, in bed, wherever… you’ll be surprised how much information you can pull out a book if you take the time to actually absorb it.

Don’t forget magazines and journals, although we’re rather deprived in the UK of any decent regular publications.

A few sites I’d recommend:

• Smashing Magazine
• CSS Drive
• A List Apart
• Web Designer Wall
• Design Float
• DesignM.ag

And a few books to check out:

• The Principles of Beautiful Web Design (Jason Beaird)
• Designing with Web Standards (Jeffrey Zeldman)
• Web Design Index by Content
• Bulletproof Web Design (Dan Cederholm)
• Web Standards Solutions (Dan Cederholm)

They should keep you busy for a while. And that’s before we even consider the various branches off web design itself. So get yourself an RSS reader like Bloglines and get into the routine of checking decent sites regularly and sourcing as much valuable information, resources and tools and inspiration as possible.

Meeting / making contact with people

Making contacts within the industry can only benefit you. It may lead to job opportunities and work but also creates new avenues through which to learn from others.

You can meet new people through all sorts of mediums, such as:

• Social networking sites like Facebook, Twitter (follow me!) and Digg
• Contacting other designers through their contact pages on their sites
• Attending web conferences and meet-ups. In Manchester 2 popular regular meet-ups at the moment are GeekUp and Northern Digitals.
• Bringing other people in on jobs can teach you a lot – sometimes it’s better than struggling to work out how to do something when you can pay someone to teach you or help out.

I talk – you listen

I know, it sounds ridiculously obvious but get talking. To mates, to people you know in the industry, to colleagues or fellow students. Ask questions, try to help each other out and share intersting new finds with others. Share the wealth!

Teach

Doesn’t agree with the idea of ‘improving yourself‘? On the contrary, teaching is one of the best forms of learning. Whether you’re teaching a friend how to use Wordpress, writing an informative blog article (as I am now), lecturing a class or giving advice in a forum; the processes you have to go through to gather the information in the first place, then absorbing the feedback and further questions that develop, creates a perfect environment to learn so much more, almost subconsciously.

Blogging

Blogging helps to improve yourself not just as a designer but in so many various ways. Redswish has forced me to learn new things to create interesting articles, my writing style has improved and my understanding of the ‘blogosphere’ and social web has improved.

What to blog about

It depends on what you wish to achieve from your blog, whether it be commercial or personal gain. If you want to make money from your blog, prepare to work hard writing regularly and building your site to pull in traffic. But if you just want to ‘express yourself’, promote yourself or just want to write and pass on knowledge to others – then do it as when you feel like it. Don’t feel pressured to blog.

Blogging isn’t for everyone. It takes a lot of time, energy, focus and dedication. Sometimes it doesn’t pay off, but it’s always worth giving a shot.

Taking criticism

This doesn’t just refer to blogging but all forms of criticism. However if you go out on a limb and broadcast your views and writing to the world – you can rest assured that some people are compelled to spite you, whether it be justified or not. Prepare for a few off-colour comments.

Criticism isn’t always constructive, but try to imagine why the comments have been made and consider how you can improve on this and try to avoid it happening again. Do not react harshly – angry retorts can drive visitors away and do nothing for your profile. Words can easily be misinterpreted on the web so be careful.

Useful input from commenters

The main benefit of comment areas on blogs is the opportunity for readers to contribute and provide their own expertise and insight. Take full advantage of this, promote it and try to generate conversation with your commenters. Doing so will help to increase the chance of more input in future.

Pushing yourself when working

All the above are examples of ways to learn new tricks and skills, expand the imagination and develop a better understanding of the industry. However, improvement can be established constantly while working in your existing environment. A few tips:

• Working for an agency. Working in an environment with other professionals is a perfect environment for absorbing new tricks and ideas, as well as sharing. Since I started working at Flame Digital 4 months ago I’ve progressed in leaps and bounds and can honestly say I’m loving it!
• It’s never too late to go back to school. More and more web design and development related courses are popping up – you’re never too old to mooch along and check out the benefits.
• Find ways to measure progress. Set targets, aim to reach them in 1 month/6 months. This will help to push you to develop, and acts as a measure to observe how much you’ve improved.
• Money is a motivator. Let’s not lie, we can design for the love of design but if you do it for a living – money is essential. Loosely speaking, the better a designer you are – the more money you’re likely to earn. It’s not always as simple as that but money is certainly a powerful motivator – perhaps the thought of that salary raise will entice you to push that little bit harder.

Explore other avenues of creativity. Design doesn’t have to remain in Photoshop on your monitor. Grab a camera and go for a walk to capture some photography, or grab a sketch pad and relax in the garden and swap the mouse for a pencil! Try to seek creativity and inspiration in different forms.

Focusing on design

I’ll hand you over to a nice article on a new website, Web Design Ledger, written by Adelle Charles, that covers ‘10 easy steps to become a better web designer‘.

The article outlines ideas and techniques that should be considered constantly and should be second nature to designers:

• Build a toolbox. Create a tidy catalogue/toolbox or resources, scripts, background and stock images, bookmarked sites, tutorial files, plugins, .psds etc. You never know when they might come in handy.
• Think on paper. Always default back to paper before you start squiggling away with the mouse.
• Keep up to date with trends. The web is like the catwalks of Milan and Paris – new fashions are revealing themselves all the time. Keep on top of what’s cool, or even get a step ahead and set the trend!
• Know your audience.
• Ask other’s opinions.

Read the full article here.

Self-improvement

‘Improving yourself as a designer’ requires a lot more than reading books, toiling through tutorials and blogging around. There are so many contributing factors that make a good designer, and these vary from person to person.

Perhaps it’s a case of building confidence, or even suppressing an ego. You can never have too much inspiration and in such a fast paced industry – there’s never any way you can know everything.

Whether you’re a student doing a part-time course, an experienced industry veteran, an up-and-coming design superstar or a jack-of-all-trades; I hope there’s something in this article that may have proved useful to you.

Never settle for second best, and never assume you’ve covered all the bases – there’s always room for improvement.

In the predecessor to this article, ‘Accessible web design – the whats and whys‘, I discussed the advantages of building accessible websites, what accessibility is and why we should be taking it seriously. In this article I’ll be running through some of the primary tasks to consider when building accessible sites.

Images

Images are often the first element considered when we talk about accessibility. Images feature heavily in web design, whether they are used in the construction of the layout or to aid the content – few sites are image-less. However, these images may prove useless to visually impaired or blind users, or anyone using a device or browser that doesn’t render imagery. In these instances, images can become hurdles as opposed to aids.

The alt attribute
The alt attribute provides alternative text to describe your images. It is placed within HTML elements just as any other attribute:

<img alt=”Descriptive text goes here” />

Describing images is important, especially if the image has a purpose (eg. logo, complimenting the copy, image link). If you don’t describe the image, it will make no sense to anyone who can’t see it.

null alt
If a particular image is meaningless, for example if it’s purely for decoration or to space layout elements, use alt=” “. There’s point describing an image that doesn’t have any purpose (ie ‘Spacer image’). This will just hassle users.

Common sense?
When describing your images, give them sensible descriptions which make sense and convey valid meaning. This doesn’t mean lines of text, just something short and sweet that makes sense. If the image links somewhere, describe where it links, for example:

Bad: alt=”logo_small_80×60″

Good: alt=”XYZ homepage”

Where’s my image!
Ah, the other benefit of the alt attribute is for those times when the images just don’t load. One of the great mysteries of life – everything else appears, the image is there on the server (or maybe it isn’t) but it sure as hell hasn’t popped up on the screen. So the alt text kindly steps in to replace it. It may not be sexy but it will provide insight into what should have been in that big white space.

Alt text for background images?
Well, if you’ve built your site semantically using CSS then all background images should be called through the stylesheet, therefore no alt text is necessary. In fact it’s impossible anyway. You can only apply the alt attribute to <img /> elements.

Links and Colour

When creating styles for links on a page, consider that not everyone can see colour. I, as you can tell by this site, am not currently practicing what I preach but will be taking it into account in the future.

If you use colour to denote links or click-able content, reinforce it with other methods such as emboldening or underlining. Otherwise colour-blind users may see no difference between standard copy and click-able links. However you go about doing it, it’s important to highlight links with more than one method.

Also, be careful that your copy and links don’t blend in too much with the background colour. Some people can’t pick out contrasting colours as well as others.

Don’t rely on colour to guide users. Methods such as ‘click on the purple box’ or ‘follow the red line’ may be deemed useless to colourblind users.

Flash!

EEk, there she is. You may or may not be surprised to know that Flash is actually quite accessible on some levels. It meets several Section 508 requirements including:

• Content magnification and scalability. Flash is predominantly built with vectors objects and so can often be scaled without distortion.
• Mouse-free navigation and keyboard accessibility. Flash offers tabbed browsing like in HTML but also provides a higher level of keyboard interaction.
  
• Visually/audibly engaging. Flash uses interactivity, dynamic visual effects and audio that may appeal better to younger users or people with cognitive disabilities.
• Custom colour palette support. Flash isn’t restricted to web-safe colours as with CSS, which of course can be taken advantage of to aid colourblind users.

Of course Flash still, being Flash, has it’s disadvantages.

• Some devices, such as the iPhone, plain don’t support it.
• Without captioning, Flash may prove completely useless to blind or deaf users.
• Flash can’t always be read by screen readers.
• Strobe effects and fast moving objects may prove difficult to understand or see clearly to anyone, not just visually inpaired users.

When it comes to Flash, I’m no expert. For more information on accessible Flash development check out ‘Creating accessible Flash content‘ and Macromedia’s white paper on ‘Best practices for accessible Flash design‘.

Structured Markup and CSS

I’d love to think that eveyrone was building semantic, well structured XHTML and CSS websites today but they’re really not, it’s a great shame. I haven’t got the time here to launch into a full article about semantic markup but I’ll touch on a few points.

Why? Oh yeah. Not all browsers use stylesheets so ensuring your HTML is valid, semantic and well structured will ensure it looks perfectly ledgible when the CSS is on vacation. Using the correct formula of HTML and CSS will also help to ensure that your site doesn’t break in different mainstream visual browsers (although it by no means guarantees this), it will make it easier to implement new content, scripts, imagery and more than anything makes it so easy to change massive details with one or two lines of CSS.

Lose the tables.
Use tables only for tabular data. Websites should be structured with divs, headers, paragraphs, lists and the odd spans and bits here and there.

Use lists for menus.
Whenever you have a menu, a list of links or even just a list – make sure it’s displayed that way. Use <ul> and <ol> to create lists, this will render as nice bullet points when no CSS is available. Chances are it will make your lists a lot easier to style up anyway.

Avoid ‘divitis’
Yep, divs are great. But you really don’t need loads of them. They contain blocks of content and are required for the central areas of your layout. However, most HTML elements can be individually styled and don’t need wrapping in extra layers of divs. This will reduce the file size of both your HTML and CSS and will clear unnecessary code.

No inline styles
Firstly, you don’t need to – get them all tucked away in the stylesheet. They add weight to the file size and aren’t always rendered correctly by different browsers.

Sure, there’s a wealth of information on this subject. If you want to learn how to build websites properly, aside from the plethora of information you could gather from a quick Google search, I would also strongly recommend Jeffrey Zeldman’s ‘Designing with Web Standards‘.

Cross-browser compatibility

So you’ve added your alt attributes, checked your links, and you reckon your markups pretty bob on. Your site looks great in Firefox (because that’s the coolest browser, of course). So what about Internet Explorer 6, and 7, which hold an estimated nearly 80% of browser market share?

When considering browsers, the main contenders on the market are:

• Internet Explorer 6
• Internet Explorer 7
• Firefox 2
• Firefox 3
• Safari
• Opera
• Camino
• Chrome
• Soon – Internet Explorer 8

To be honest – the list goes on. Personally, I’d recommend you always check your sites in IE6, IE7, FF2, FF3 and Safari. I know budgets don’t always cover it but they should do, and it may seem like a lot of effort and it can be. But regardless of accessibility, from a general Usability point of view – can you afford to lock these users out?

When tweaking your sites to render well in other browsers, don’t be tempted to use invalid CSS or HTML – this may affect other browsers that don’t render styles in the same way or even at all. I can assure you that all the main visual browsers can be catered for while using valid markup.

Validation

I’ll shamelessy tell you here and now that validation isn’t imperative. The majority of modern browsers can pick up on slight errors and either work out what you’re trying to do or produce an adequte alternative. Your sites do not always have to pass the W3C HTML and CSS validators, or Bobby or another generic ‘Accessibility test engine’ to be accessible. But to be honest, is it so much to ask to write your code correctly?

But don’t think for one minute that just because your HTML is valid and you’ve slapped a pretty little W3C ‘valid xhtml 1.0′ badge at the bottom of your site that it’s accessible. These validators don’t take into full consideration what font size you’re using in the text, the fact that your header colour may be low contrast against the background colour or whether your alt attributes acurately describe their parent image.

Scripts

There are 2 definitive rules to bare in mind when incorporating Javascript into your site.

1. All scripts must be stored in an external Javascript file. No inline scripts unless absolutely necessary.
2. All Javascript must be degradable so it doesn’t affect users who don’t have scripts turned on.

When developing in Firefox, I’d seriously reccommend you get hold of the Web Developer Toolbar plugin. This allows you to easily check how your site looks with/without scripts, CSS and has lots of other nifty features.

With Javascript languages such as jQuery and Mootools getting real popular – designers are spicing up their sites with non-intrusive and majoritively accessible Javascript, which is good! But always check that your site works full with all the scripts off or some users may get a nasty surprise.

Typography and Font Size

The area surrounding choices of typography, web-safe typography and scalable font sizes can get quite deep. Current browsers will only render fonts that are also present on the users system. So if you go designing and building a site with a great looking downloaded font – chances are only a very, very small fraction of visitors will actually benefit.

Web-safe fonts

Unfortunately, advances in general web font support have been small. We still have our hands tied dealing with the same default fonts as we were years ago. There are 3 main methods of dealing with this:

• The good way – the CSS ‘font-family’ property.
• The bad way  – “Download this font here”
• The cool way – sIFR

CSS: font-family
When specifying your website’s fonts with CSS, you can specify multiple fonts for particular elements in order of preference. Therefore, if the user doesn’t have the first font installed, it will default to the next in the list and so on. This property looks as so:

p { font-family: Calibri, Tahoma, Arial, sans-serif; }

In the instance above, users with Calibri installed will see the paragraph fonts in Calibri. If not, it will default to Tahoma which is a relatively safe bet. Failing that, Arial will be used and in the most basic scenario the generic sans-serif font will be used.

“Download this font”
This is seen very rarely in modern design. But some designers force visitors to actually download the actual font file and install it on their machines so they can view the site in the designers selected font.

Not only is this completely inaccessible and unusable, it’s damn right unethical in some cases illegal.

sIFR (Scalable Inman Flash Replacement)
A popular option for text replacement is sIFR, pronoucned “siffer”. This is a Flash technology that replaces HTML text with a Flash rendered object, pulling in the required font from a .swf file.

This is great because it maximises the range of fonts that can be viewed on sites, breaking the mould of the restictive default fonts. And it’s completely accessible! If users don’t have Flash installed, they have Javascript turned off or their browsers plain don’t support Flash – it degrades to perfectly clean text that can be styled with CSS.

The only real downsides to sIFR are that, for the moment, it can only replace a single line of text so is only really useful for headings. Plus it can sometimes be a hassle to install and configure but if you do it enough times you’ll surely get wizzy at it.

It’s all well and good ensuring that your typography looks nice (as it’s an essential element of design) while still being accessible by all. However accessibility isn’t just about the typeface – you have to consider font size.

Em’s and Px’s

When specifying font sizes in CSS, the only units to consider are px and em:

• px (pixel) = static unit of measurement, corresponds with monitor resolutions.
• em = relative unit of measurement that equals the vertical size of an element’s text.

Assigning your font sizes with pixels ensures that they will be that exact size across the board. When visually impaired users wish to increase the font size, modern browsers feature the option to increase it, which will automatically increase or decrease the pixel size of fonts. (You can normally check out this feature somewhere in the ‘View’ menu under ‘Text Size’ or ‘Zoom’.)

The problem with this is that Internet Explorer 6 and certain other browsers don’t change the size of fonts set in pixels. IE7 features a page zoom function which does the job but this still doesn’t excuse sizing fonts with pixels. Instead we have to look at ems, which are relative.

The safest bet
The safest approach to styling your typography so that it displays at the size you want, while still being scalable by different browsers, is to set a default size in the body element. This is normally around 11px or 12px. Then use ems for the rest of the elements in your site.

If you set your default body text size to 10px, this makes it far easier to work out the sizes of other fonts as they will all be round decimal units. So:

• 12px will equal 1.2em.
• 35px will equal 3.5em.

You get the idea…

The tabindex attribute

The XHTML tabindex attribute allows your to specify the order in which keyboard users can tab through different elements on the page. By default, users who use the keyboard instead of a mouse to navigate website will tab from link to link in the order they appear in the source markup.

To apply tabindex just add the following HTML:

<a href=”#” tabindex=”2″></a>

and so on through the different elements you wish to prioritise:

<a href=”#” tabindex=”1″>Home</a>
<a href=”#” tabindex=”2″>Search</a>
<a href=”#” tabindex=”3″>Articles</a>
<a href=”#” tabindex=”4″>Return to top</a>

The benefit of using the tabindex means that users without the ability to navigate with a mouse can access the most important areas of your site faster, instead of tabbing endlessly through every link and active element on the page.

Accesskeys

Accesskeys are similar to tabindex. However, instead of specifying an order to travel through, accesskeys dictate a letter or number that represents an element. Different browsers interpret accesskeys differently. Sometimes you can simply press the number or letter while on a page but in most cases you have to either press alt/ctrl and the value to access it.

Apply accesskeys like so:

<a href=”#” title=”Return to the homepage” accesskey=”h”>Home</a>

The problem with accesskeys is that more often-than-not they’re not accurately depicted. So users don’t know what to press. It’s often a case of common sense – usually the first letter of the link title or the number of the item in the list in the case of menus. Sometimes a visual guide is given, yet sometimes they prove compeletely irrelevant.

Just don’t even do it.

To be honest, if you’re still designing websites with the techniques below… why? These were dirty elements that were on their way out when I first started playing with Freewebs and Dreamweaver MX.

• Image Maps – No. There’s no reason to be using image maps anymore. Opt for Flash or Javascript to really do justice.
• Table Layouts – No. Le’ts get semantic guys! Lose the tables and get with the structured XHTML and CSS.
• Spacer GIFs – No. Real simple – CSS > margin-top: 15px; = no pointless, bandwidth hugging, inaccessible spacer images.
• Frames – Absolutely Not.
• Applets – Nope, not here.
• Flashing and blinking elements – Most definitely not. Next time you create that family business site with some cheap WYSIWYG site builder with built in ’snow effects’ or ‘flashing banners’ – go and knock your head on the wall and see the error of your ways. Do I honestly need to hold your hand to help you realise how inaccessible and darn right ugly these elements are.

On your way to becoming a better designer

Accessibility isn’t something you pick up over night, or indeed simply from a blog article such as this. In fact, it’s not a strictly defined set of rules or protocols that can just be learnt then adhered to and varies with every website you will build.

People such as the W3C, The Web Standards Project and the WAI are working every day to push for new changes and to evolve the mindset and general acknowledgment and acceptance of Accessible web design. It does benefit you as a designer or developer. It may not necessarily mean your designs look any better but will ensure that more people will gain access to your work, and demonstrates good ethics and consideration as a forwards-thinking member of the industry.

Where to next?

I’ll leave you with a few places to check out for far more information. If you wish to add anything please take full advantage of the comments section:

• The Guild of Accessible Web Designers
• W3C
• WAI
• Section 508
• The Web Standards Project
• A List Apart
• Web Content Accessibility Guidlines 1.0

Throwing a shout out to my latest post, however not on Redswish. My first (I think) guest post has been featured on ifoh designs blog.

The article covers, or at least attempts to cover all the bases to consider when designing usable website navigation. It looks at page quantity, hierarchy, design aspects, accessibility, consistency and navigation design on different types of websites.

Quick teaser quote:

Consistency is essential. Nothing is more confusing than traveling to another page on a website, only to loose the navigation, or find that it’s changed format or location. Ensure that your navigation, whatever layout and positioning it may take, remains in the same place on every page of your site – even if the color scheme or rest of the page layout changes.

A simple ‘Return to the main site’ style link will not suffice.

But hey, don’t take my word for it, it’s my article! Check out the full article here:

http://ifohdesigns.com/blog/web-design/creating-usable-website-navigation

Thanks to Matt Rossi for the opportunity. Leave feedback wherever you want!

The fundamental functionality of Custom Fields provides you with the ability to expand your posts and their content. They allow you to include extra information and features in your posts that the WYSIWYG editor doesn’t provide itself.

How it works.

When in your Write/Manage posts page, mooch down past Tags and Categories to the Advanced Options – ooh! Down here in these murky depths you’ll encounter the Custom Fields box. In here you’ll see 2 empty textareas labelled key and value.

The key is the name for your custom variable, and the value is, well, it’s value! When you create a custom field, you are creating new meta-data. You then insert a simple line of php into your Wordpress template where you want this extra data to appear in the theme and voila! You’re done.

So, the easiest way to show you is with a short example.

Adding Subtitles to your post

I feel subtitles serve more as a presentational feature than anything. And sure, you could always just insert a h2/h3 at the top of your post to act as a subtitle. But sometimes that doesn’t cut it, especially if your subtitle needs to stand out from the post content more than an standard inline header.

Step 1 – Theme files:

In your Wordpress theme, you need to enter a line of code to pull in your custom field. Make sure this is within the post loop, the most obvious place is of course directly under your post title. Here you go:

The only bit you may wish to change is the keyword within the parentheses. In this case ‘Subtitle‘. This ties in with the key you create in the post editor, so make sure they’re the same. And only use it again if you wish to display the subtitle somewhere else, for any other custom fields you’ll have to change this.

It would make sense to place this code within header tags:

That’s it for the code!

Step 2 – Post page:

When you’re writing or editing a post, go down to the Custom Fields area in the Advanced Options. Create a key which correspondes to your keyword you set in the code. The value will be the actual Subtitle content. So for example: Key – Subtitle Value – An inside look at Google’s new browser… Add your custom field and save your post.

Step 3 – Check it out:

Check out how it displays on the page. Then utilise the power of CSS to get it looking bob on!

Having more fun

Let’s face it, subtitles aren’t that interesting. But there’s a lot more you can do, a lot of which I’ve still yet to discover. Post Thumbnails

Add the following code to your theme:

" alt="" />

This will include an image, pulling it in from a specific folder. So if you upload all your thumbnail images to the directory /wp-content/post-images/ and then in your post editor set the key as ‘Image-Thumb’ and the value as your image name (eg. picture.png), this will pull in your thumbnail picture and place it in your post. You can control the appearance of the image with CSS.

To actually upload your images to the specified folder, you can use good old FTP or a plugin I’m particularly fond of, because it keeps you in the WP admin area without having to use any external programs: Filosofo Old-Style Upload.

Of course this doesn’t necessarily have to be a thumbnail, it can be a full size image, adding plenty of colour and interest to your blog articles.

For a more advanced alternative to this method, check out Justin Tadlock’s method.

Meta-Data

Some of the examples given on the Wordpress Codex page on Custom Fields are the simplest, and the best. What if you fancy adding information relating to your current mood or the weather at the time of writing your post? Try:

Current Mood:

Key: Mood
Value: Happy
Code:

Current Mood: 

Displays: Current Mood: Happy

Listening To:

Key: Listening-to
Value: Fly me to the moon – Frank Sinatra
Code:

Listening to: 

Displays: Listening to: Fly me to the moon – Frank Sinatra

Other ways to display meta-data

To pull in all the meta-data for a post in one fell swoop, go for:

Which will display all the meta-data in an unordered list and add’s classes that can be styled with CSS.

If you want to pull meta-data from a specific post, you can specify which post by the post ID, which data by it’s key and whether to display the data as a single item or pull in an array:

• $post_id is the ID of the post you want to select data from
• $key is the name of the meta-value you want
• $single can be either true of false. If true it will pull in a single string of meta-data, if false it will pull in an array of the custom fields.

Go Play…

Like most things, Custom Fields open doors which you have to walk through and explore. In essence they’re very simple but if used correctly can be pretty powerful, another extension of the basic functionality of Wordress. So go forth and experiment!

For more information on Custom Fields and all things Wordpress – visit the WP Codex.

I personally probably prefer offline. Having debated with co-workers, print media seems to take the glory. This is down to a number of factors including a lack of distracting menus, images and adverts, the easier readability, the option to have a book open in front of you while keeping your monitor free, and because your are almost always guaranteed more high quality content from a book.

Check the post out here. And comment where you like!

I would like to make a toast to the fantastic selection of web design/development oriented books delivered from Sitepoint. I own only a couple myself, the best of which is ‘The Principles of Beautiful Web Design‘, which I must say is a awesome book and reference.

Whether you’re a designer, client-side or server-side developer, project manager, freelancer, hacker, CSS Guru or jack-of-all-trades – you can be assured there’s something for you (how cheesy does that sound.)

My only advice would be to actually buy the books from Amazon – far cheaper. But check out the Sitepoint website anyway – it’s crammed with tutorials, articles and resources and is well worth bookmarking.

A recent post discovered through Smashing Magazine got me thinking about a topic that effects me every day within my line of work. When I started designing websites 2 years ago I was led to believe at the time that sites couldn’t be made any wider than 750px, (780px max) to compensate for people using monitors at 800×600px resolutions. This is accessible – this is caring for our users?

Over time I began to get sick of 750px. I was designing on a 19″ PC with Firefox at 1280×1024px. Why wasn’t everyone else! Annoying people with their 15″ 800×600px resolutions (for example my secondary school). I then began to consider, with no appropriate research, that the majority of people now used 17″ monitors at a resolution of 1024×768px. So I’ve stuck to this for a long time – designing sites anywhere from 800px to 950px wide.

Just for the record – I don’t like variable width sites. It works for shop sites, some galleries and that’s about it. I don’t feel it’s necessary and I hope this post proves this. The article that sparked this post regarding Flexible Layouts, is extremely well written (by Dirk Jesse) and perfectly valid – however it doesn’t change my views on flexi-width layouts.

Stats Time

An up-to-date chart demonstrating the different resolutions used over the past 8 years, courtesy of W3 Schools was featured in the post:

What this graph shows is a typical model of the product life-cycle. One product grows and matures, then as it begins to decline the next product is introduced and begins to grow. If this graph led back 20 years or so the curves would quite possibly represent a mountain range!

What this chart proves is that as of today, 2008, the majority of web users are viewing the online world at a resolution of 1024×768px or higher, with no more than 8% of users at 800×600 or less.

So why should we still consider this small percentage of users? We shouldn’t. Not everyone will be going out over the next 2 years to buy larger monitors, the number of small-res users will never drop to zero, at least not for a very long time. But one of the biggest hurdles with web design is trying to please everyone, but it can’t always be done. I refuse to build sites that will render correctly as low as IE5 because if people are still using that version (heaven knows why?) it’s their own fault.

So what I recommend:

What I do now. I don’t plan to change. If the average monitor resolution is 1024×768px, I will design sites no wider than 1000px. These will render well on virtually all monitor sizes. There is no argument about massive Apple/iMac monitors at high resolutions because Mac users don’t use maximised browser window like on PC’s – there’s simply no need. A website at 950px will look great at anything from 1024px – 1600px wide. I promise.

Don’t forget height:

So far I’ve focused on width. But don’t forget the importance of height when designing sites. If the majority of monitors are displaying at 768px height, and assuming that most people use their browsers maximised, take away the 100-250px or so for navigation and toolbars and we’re left with around 550px of real estate known as ‘the screen’.

This is the web version of a newspapers ‘above the fold’. This is where it’s essential to make an impact – ask any copywriter. Try not to create too big a margin or white space at the top of your site. My personal opinion is to get at least the logo, navigation and a selection of ’splash’ information within the first screen.

The aim is to drag users further into your site and direct them to where you want them to go – whether that be to the checkout, email form or an interesting article; a massive, pointless header can immediately damage that first impression of your site if the viewer has to scroll down to reach content.

On Variable Width…

Use by all means if you can get it right and it’s necessary. Sites like Amazon pull it off well because it serves a purpose. I can’t personally understand why people choose to design variable width – it makes everything harder.

I like to work mathmatically, hence why I’m a fan of fixed width. I don’t work in percentages – I like my sites to be pixel perfect so everything slots in right and renders well across the board.

The site I’m currently working on (hush hush secret project) uses a fixed left column and a variable right with the occasional third column, floated right. It’s not been an easy build and I would still prefer it fixed width but another web design hurdle is pleasing the client.

And sometimes, unfortunately, compromises have to be made!

I have to post this because I want to spread the word. I haven’t had this problem for a very long time because of the designs of my sites. But today I’ve been working on rebuilding someone’s site with valid mark-up, and while converting the table-based layout to semantic divs – I encountered the dreaded Firefox Height bug.

This problem is when you have a ‘container’ or ‘wrapper’ div that has a background image, colour or border that you want to repeat to the bottom. Unfortunately, specifying 100% height in your CSS for the html or body just doesn’t cut it – the background will only stretch to the bottom of the viewable window and no further when you scroll, or for some reason just doesn’t even display at all.

Anyway, after lots of hunting and stressing out, I’ve found a fix which wonderfully works! As so:

#wrapper {
width: 775px;
min-height: 100%;
margin: 0 auto;
border: 1px solid #888;
}

.clearfix:after,div#wrapper:after {
content: “.”;
display: block;
clear: both;
height: 0;
font-size:0;
visibility:hidden;
}
.clearfix,div#wrapper {display: inline-block;}

/* Hide from IE5/Mac \*/
* html .clearfix {height: 1px;}
* html div#wrapper {height:100%;}
.clearfix,div#wrapper {display:block;}
/* End hide */

In the instance of my example, I use ‘wrapper’ whereas many use container or something similar.

It works for me – I sincerely hope people discover this and find it useful. Let me know if it helps!