• XHTML Strict 1.0 W3C valid markup.
• Semantically correct markup – e.g. use <ul> unordered lists for any list of items.
• Common identifiers should be used based on potential HTML classes and hCard microformat.

Cross Browser Valid:

• Identical (and fully functional) user experience across browsers. (note: browser differences for font anti-aliasing are expected) – Internet Explorer 6, 7 & 8 + Safari 2 & 3 + Firefox 2 & 3 + Google Chrome + Opera 9 for Windows XP | Firefox 2 & 3 + Safari 2 & 3 for Mac OSX.

CSS Styling:

• CSS styles must be completely unobtrusive with no inline styles.
• Elements should not be positioned absolutely unless necessary – All main element blocks should normally be positioned relatively so if new content is added the existing elements would automatically reposition in the flow. Also wherever font-size is increased the layout integrity remains.

Client side scripting:

• All JavaScript should be unobtrusive and loaded / called through external files – using IDs or Classes as hooks, no inline JavaScript such as onclick functions.
• The existence of Functions and Objects should be tested for before use where practical.
• The jQuery library is preferred.

Accessibility:

• JavaScript features are unobtrusive and the dynamic features degrade well with scripting disabled: All content should be accessible with JavaScript disabled including hidden or asynchronously included content. (e.g. Content asynchronously included with AJAX is replaced with a standard link for screen readers or clients with no javaScript.)
• Content should be accessible via keyboard for users without mouse control.
• Using meaningful ALT text for information images.
• Links should have descriptive hyperlink text and titles warning of link actions.
• Text colours have adequate contrast for colour blind/challenged users.
• Avoid the use of frames, which are difficult for special browsers to interpret.
• Keyboard shortcut to main content available.
• Labels assigned to form items and forms have accessible design.

Usability:

• Links, buttons & other dynamic elements have hover states, focus states and active states.
• AJAX calls include history recording for forward / back buttons and bookmarking / links.
• Navigation menu will only activate when the user intends to use it – i.e. user slows the cursor down over a link. The menu is not activated if the cursor is dragged across the menu. (through a delay or hover intent script)
• Search field has suggestion. This is greyed out until the user starts typing.

SEO:

• Site is fully available without JavaScript.
• Semantic mark-up with consistent URL, breadcrumb and content titles. Where titles are graphical, <h1> image replacement techniques are used.
• CSS coding allows the content to appear before the top and left navigation in the source code. Spiders will arrive at the header then the <h1> tags at the top of the content. They spider the content first then the navigation and footer last – enhancing SEO.

Optimization:

• Repeating background image layers used for reoccurring design patterns.
• Dynamic graphical elements preloaded and highlighted using CSS sprites technique.
• AJAX used to pull in optional content where file size may degrade performance.

Accessibility issues that are not priority 1 issues and do not fail the legal Accessibility guideline requirements:
- Text input fields with a default value – Text fields may have a default value – but only for users with JavaScript enabled (96% of users). This is so that a ‘dynamic’ default value can be added that disappears when the user click in the box. This is a superior solution but not 100% accessible to people with disabilities.
- Adjacent links are separated by white space – CSS is used to separate some adjacent links. This can make it difficult for some older assistive technologies (readers for the blind). This is done to improve performance and ease of future updates. People should update their older assistive technologies.
- Web colour scheme may not be tested against protanope, deuteranope, and tritanope colour-blindness.
- Form fieldsets do not have legends. These are normally catered for by titles, or left out when the design requires.

Here’s a few tips to bear in mind now we have a new range of browsers.

Accessibility needs are becoming more important as a solution to giving cross-browser accessibility to everyone. It’s not just people who have accessibility needs, now it’s devices, or ‘thin clients’ which are having accessibility issues.

There’s some new rules for ensuring your web site works with browser zoom or in the new mobile browsers.

Phone browsers

There’s two new browsers in town: Apple IPhone and Opera Mini (testing on version 3.1.2). They shrink full websites down to a small screen size.

1. Css media=”handheld” is ignored by the iPhone and Opera mini browsers. They think they’re real browsers. Any style-sheet with media=”screen” will be rendered by these phone browsers.

2. Zoom isn’t a raster zoom. The text font size is reduced independently to the spacial elements. It should be reduced by exactly the same amount but it doesn’t always work perfectly.

– If there’s a mix of different size fonts on your page, the zoom will try to maintain their relative size ratio. So, for example, if the navigation has a text size that’s a lot bigger than the body text, it’s likely it will look too big on a phone browser.
- Piped lists are tricky. If you just add a right border it gets all squashed up. There’s been a lot of work on developing a piped list (e.g. ‘link1 | link2′) with the best possible mark-up and all presentation separate in the CSS. Brunildo’s CSS piped list is one of the best – and it seems to work well with browser zoom. He uses the cssplay min width technique.

3. Opera mini doesn’t do DHTML well. That means it doesn’t do show-hide toggles, carousels, or menu drop-downs properly.

Here’s what they say at the Opera Mini Dev Center:

1. Limited support for DOM events
2. No background scripting
3. Very limited Ajax support

So all those people who said your web page should be accessible with javascript disabled may have had a point.

The iPhone can handle these properly.

4.Sliders, dials and drag-drop functionality

Accessible user interfaces are needed for phone browsers with touch screens. The touch screen function is used to either scroll the page or for zoom using the iPhone’s new ‘pinch’ functionality. This means ‘draggable’ controls cannot be used with the touch screen technology. This includes sliders, dials and drag-drop elements. So long as the control can be brought into focus and controlled using keys, it should be possible to operate them on some touch screens but the iPhone has no access at all.

5. Flash does not work on the iPhone or using the Opera Mini Browser.

Zooming on ‘computer’ browsers

1. If people use the zoom in the Opera browser you need to ensure you select background colours properly. Divs with background-color: transparent on top of a div with a white background – it turns black. You need to set the background-colour to white. (This doesn’t seem to cause a problem in the mini-opera phone browser.)

2. Zooming on IE7 – watch out for your floats. This won’t affect most sites but some liquid sites using opposing floats can be affected. (You don’t see any of the float issues seen in IE7 (Opera and Opera Mini pass the acid test).)

Click here to see the test

The new box model hack

Safari isn’t a new browsers, but it’s now more widely used.

If you have a liquid layout you’ll find you need to set the width to 100% for some elements to expand properly in the Safari browser.

Now if that 100% width element contains no text content and you float it against another element, such as a column or an image, Safari can expand it over the second element. The other browsers just expand to the adjacent floated element.

If you pad up an element on the side it’s sibling elements are floated against, Safari will add the padding to the other side. A workaround is to wrap the div so you can use margin instead of padding.

You can use Google’s script to do this automatically by running it on your (host’s) server using Python or you can create a sitemap manually with an xml page. Including valid xml tag definitions is a sure way to improve the validity of search results.

This is an example of how the xml page is structured:

<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">
<url>
<loc>http://www.example.com/
<lastmod>2005-01-01
<changefreq>monthly
<priority>0.8

Google have a sitemap validation tool available from their support page.

Once you have created a sitemap you need to log in to a google account and find the webmasters area. There you will submit the sitemap address and verify site ownership. Once you do that Google offer the GooglAnalytics information ( Query stats | Crawl stats | Page analysis | Index stats | HTTP errors | Unreachable URLs | URLs restricted by robots.txt | URLs not followed | URLs timed out ).

Search engines are increasingly an important marketing tool for all business - especially those who's brand is not widely known. Appropriate keywords, content and one-way links from high pagerank sites are the main factors for success.

Other factors include:

• The way a site's mark=up (HTML) is structured is important. Using the page title and heading tags (H1, H2 etc.
• The way the site is linked together - ie. the navigation system and internal links within the content help if done well
• URLs for variables (e.g. site?p=page1) are disliked by search engines.
• Using frames is a bad idea.
• The amount of time the domain has been in use (by the current owner - google checks this) is a factor.
• The frequency it's modified.