Whilst working on a few design tweaks on the X-O website, we noticed that a significant percentage of all users were using the iPhone to browse the website. This was backed up by users requesting an iPhone version.
At the time, this audience was viewing the full version of the site, designed for larger screens. The user experience therefore involved a fair amount of scrolling left and right.

We recommended that we use the WordPress plugin WP Touch to select a different iPhone specific style sheet with reduced content.

The iPhone version of the site as been well received by the user community and has helped increase the number of hits to the site from iPhones.

For more information, please visit – www.x-o.co.uk

DEVELOPMENT:

The Amount and sophistication of the plugins for Word Press is outstanding. We’d need 100’s of programmers to keep up. Along with the standard WP plugins, we also develop Plugins for our Industry specific modules. The Plugins integrate with the standard WordPress tools – e.g. media library. This means we are no producing the same systems as everyone else.

HOSTING:

Our propriety CMS used a number of specific libraries and modules in order to run. The upshot of this was that it became very complicated to install our CMS and so had to run our own hosted dedicated servers. Due to the massive peaks in activity on our sites, the ideal hosting environment for us would be to host the sites on Virtual Servers – Elastic Cloud. However, hosting on Virtual Servers requires you to be able to build servers at a click on a button and that was not possible with all the required dependencies our proprietary CMS had.

TRAINING:

The training resources for Leading Open Source Platforms is amazing and largely FREE.
I’d be happy to discuss our experience in this area and provide consultancy in this area.

The following points are what can be done to optimise website pages using the Miramedia Content Management System (CMS) and improve search engine results for target keywords.

• Firstly decide on a list of keywords for each site – the words that might be typed in a search by the kind of people you are trying to attract to the site.
• Make main headings (“Heading 1” from the “format” dropdown in cms) on each page as descriptive as possible and include your keywords where possible (the words you want to be found by).
• Make sure the ‘meta data’ for description and title (see button at the top of each page when editing a page in the cms) is filled in on every page in the site, this can match the h1 title and additionally include some of those keywords. However don’t go over a limit of say 10 words for title and 15 for the description. These same keywords need to appear in the page content as much as possible.
• Add your keywords to the meta data keywords section, however this is less used by search engines these days, it’s more important to use these words in your links, headings and copy on the page.
• Aim to have a body copy of 250-400 words where possible.
• Use the “Heading 2” and “Heading 3” sub headings with as many target keywords in as possible.
• Use bold to highlight text and phrases here and there, it gets a higher importance than normal text, again dropping in the odd key word.
• Use descriptive links with key words in, rather than ‘click here’. For example “exhibitors showcasing the latest prints, rugs, mirrors, cushions, ceramics and glassware”
• You can use anchor tags with a list of linked subheadings at the top of long pages (like an index). These will be picked up as keyword phrase links too.
• Link to other pages in the site as much as possible. Make the link text match the Heading 1 of the destination page if possible. This is also good for keeping visitors on the site longer as they will not get to the end of the page and reach a dead end. Good links can be used to guide a person round a site as they read.
• Link to external sites where possible and get as many of those sites to link back to you as possible.
• Fill in the ‘description’ for all images in the pages, again using as many of your relevant keywords as possible.

Do the above on all the pages in the site and make updates to the site copy as often as possible, especially the home page. The copy changes need not be big ones.

Although a lot of emphasis is placed on placing keywords around as much as possible, by writing your copy as normal you’ll find the keywords are often naturally there already, it’s just a case of making sure there are links containing them, and the meta titles and description on all the pages.

A Summary of what you get:

Advice on selection of keyword phrases and the website pages they will target (15 phrases)

• General technical advice on how the website template and pages can be improved for search engine visibility
• A report showing the density of keyword phrases on target pages after optimisation

• Optimisation of each target page for the keywords – includes h1, h2 heading tags, custom meta title and descriptions, link anchor text, image ‘alt’ text
• Update on positioning 1 month after the initial measurement plus further 1hr of improvements of target pages

• Creation of XML sitemap and reporting of broken links
• A Google Webmaster Tools account set up and XML sitemap submitted
• Submission to DMOZ directory and up to 2 other relevant subject specific directories

• A list of link html that can be used on other websites for incoming links.
• A summary of incoming links to the site (where data exists).

We don’t guarantee positions in results but give your site the best change of being found if someone searches using your chosen phrases. We have a good track record for seeing improvements after the above SEO has been done.

Training

• Where needed training can be given on how to do this on your own site.

Extra Keywords & Updates

Extra keyword phrases can be added and further monthly reviews and improvement can be done, these can be quoted for on a per-site basis.

The Disability Discrimination Act 1995 came into force on the 1^st of October 1999. Part 3 of the act refers to the provision of goods, facilities & services, this includes the provision of websites.

Relevant points from the 175 page document:

2.2(page 7) ” The DDA makes it unlawful for a service provider to discriminate against a disabled person by refusing to provide any service which it provides to members of the public.”

4.7(page 39) “From 1^st October 1999 a service provider has to take reasonable steps to change a practice which makes it unreasonably difficult for disabled people to make use of its services.”

2.13 – 2.17(pages 11 – 13) “What services are affected by the Disability Discrimination Act? An airline company provides a flight reservation and booking service to the public on its website. This is a provision of a service and is subject to the act.”

5.23(page 71) “For people with visual impairments, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include…accessible websites.”

5.26(page 68) “For people with hearing disabilities, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include…accessible websites.”

The Code of Practice, published in May 2002, which specifically mentions websites, can be downloaded in its entirety from the DRC (Disability Rights Commision) website.

2) How do we comply with the Disability Discrimination Act

As the act is untested in reference to websites (as at 9^th April 2006, all tests have been settled by the site in question being made accessible rather than going to court for a ruling, this is most likely due to the adverse publicity that may be involved) it is hard to ascertain how we should comply (or how much). However, the common consensus is that should the act be tested, the W3C Accessibility Guidelines will be used to assess a given websites accessibility. To complicate this, though, there are three levels of compliance.

• Priority 1 guidelines (which must be satisfied according to the W3C).
• Priority 2 guidelines (which should be satisfied and are the EU recommended level of compliance).
• Priority 3 guidelines (which may be satisfied to enhance websites accessibility to the limits of current technology, and most likely future technology as future technologies are likely to be built with accessibility compliance).

Priority 1 will almost certainly have to be adhered to, with all or part of priority 2 having to also be adhered to.

3) Top 5 myths about website accessibility

1. Its complicated & expensive to create accessible sites

To develop an accessible site will cost virtually the same amount as to develop any website. Fixing a large inaccessible site may take some time but the benefits can far outwiegh the costs (through increased customers & increased usability or search engine friendliness etc.).

2. Creating a text only equivalent is sufficient

This is not necessarily true as text only versions are not necessarily any more accessible than their all singing all dancing siblings. For example, a list of items in a table may be read in a confusing manner by screen readers, whereas, in an html list it will always be read in a correct manner. On top of this a further version of the website may be costly and could involve a time investment. But, possibly more importantly, it may not be the best marketing strategy or good for society as a whole, to marginalise blind and disabled users from our websites by creating a separate version.

3. Accessible websites place restrictions on design & creativity

This is not true. For an example of the multitides of approaches to a single accessible website design see Dave Shea’s CSS ZenGarden [www.csszengarden.com].

4. Blind & disabled people don’t use the internet

This is possibly the most bizzare of all the myths surrounding website accessibility. This quote from Tim Berners-Lee illustrates the use of the internet in levelling the playing field (if you’ll pardon the cliché) for all users:

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee, W3C Director & inventor of the World Wide Web

5. Accessibility is not a legal issue as it is not mentioned by the Disability Discrimination Act.

This is untrue, as part 3 of the Disability Discrimination Act refers to the provision of goods, facilities and services. It is true, however, that this part of the act does not mention websites specifically, but then it does not mention any specific services. However, other parts of the act do mention websites.

2.13 – 2.17(pages 11 – 13) “What services are affected by the Disability Discrimination Act? An airline company provides a flight reservation and booking service to the public on its website. This is a provision of a service and is subject to the act.”

5.23(page 71) “For people with visual impairments, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include…accessible websites.”

5.26(page 68) “For people with hearing disabilities, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include…accessible websites.”

These passages from the act cover creating websites that makes sense and are usable to those using text browsers, screen readers and braille pads as well as other assistive technologies. This will need the correct use of lists, alt text or longdesc tags on images, labels on forms, well drawn and annotated graphics, transcriptions and subtitles.

4) Testing a websites accessibility…

The basic tests you can do to test your site for accessibility include:

1) Check informational images for alternative text

To test this in IE is relatively simple as Microsoft have incorrectly implemented the alt tag to display as a tool tip when hovering over an image. For users with images turned off, browsing by screen reader or braille pad or whose browsers do not support images, this is what they will see or hear in place of the image. Does the text make as much sense as the graphic it replaces? Could it be better written?

2) Check decorative or dummy images for alt text

Like informational images, decorative or dummy images should have alt text, however, the alt text attributes value should be blank [i.e. alt=""]. This is due to the way screen readers in particular read out pages to their users. If a screen reader comes across an image without alt text it will alert the user to the images existence but not to any context of the image. This will get pretty old for a user who is sitting through a site with rows of dummy gifs hearing “image” read out by their screen reader twenty or thirty times in a row before they have even got to any content. Also beware of giving the alt text for decorative or dummy images a value such as null or image, this would exascerbate the problem. Imagine sitting through twenty dummy gifs hearing either “image null” or “image image” read twenty times, that is 40 times of hearing the word image repetitively in the second case, which is enough to send anyone postal. This can be worsened if alt text is left out altogether for dummy images as some screen readers read out the file path to the image.

Writing alt text for images:

• Dummy images [spacers, null, shim etc.] should be assigned an alt value of nothing e.g. alt=”".
• Bullets and icons will also need an alt value of nothing if they are using images.
• Eyecandy should also be assigned an alt value of nothing, as they have no meaning to the user other than to make things pretty.
• Textual images, i.e. Any image where the image is only text using a fancy font or similar e.g. headings, navigational images etc., should only repeat the text within the image and not expand upon the image.
• Company logo should have alt text repeating the text in the image, although some people may use the term “logo” in the alt text too, this is not wrong but is often not necessary. If the logo is also a link to the homepage this link information should be correctly put in the title attribute of the image tag.

3) Turn of your volume for video or audio content

This test will help you judge whether the content of the audio or video is correctly delivered for people with hearing impairments. The use of transcriptions and captioning can help with this. A useful captioning tool for Windows is Magpie [http://ncam.wgbh.org/webaccess/magpie/]

4) Check that forms are accessible

If you click on the prompt text next to each box of a form does the cursor appear in the relevant box? If so good, the form is accessible, however, if not consider the use of labels to help create an accessible form. See the section on creating accessible forms later in this report.

5) Ensure that text can be resized

Try resizing the text on the site using the browser controls [View>Text size>Largest on IE on windows]. If it doesn’t resize then you may have a problem. This could be due to the way you are sizing text in the CSS. For more on this see the next section.

6) Check your site in a text only browsers

Websites can be checked in the Lynx browser to see how it will render in a text only interface. This might reveal not only problems with your code but also in the documents architecture, for example is there a lot of extraneous information on the homepage before you get to any navigational links, are the navigational links easy to understand, will the user understand where they are going?

7) Try navigating the site without using your mouse

Not everyon can use the mouse to click around. Assistive technologies allow users to use keyboards to navigate and voice commands, try using the tab, shift tab and return keys to navigate in IE.

Is there a site map?

This is a good tip for general usability as people may get lost on your site so can use the site map to find their way around.

9) Is all the link text contextualised?

Often people use “click here” as the actual link text to click. People using assistive technolgies can cycle through the links on the page without hearing the text or images surrounding those links so will this text make sense out of context? Using correct text to contextualise the link itself will help not only the accessibility but also may help with SEO.

10) Use automated accessibility checking programs

These programs can not be relied upon for all accessibility checking as they will not be abe to tell you whether the context of the link is correct. However, they may be able to help spot some areas of your site that need improving. WebXACT [http://webxact.watchfire.com/] and Wave [http://www.wave.webaim.org/index.jsp] are two free programs that you can ceck your site with.

5) Making your site more accessible

Accessibility is not only about making sites more accessible to those using assistive technologies. You can also make sites more accessible to everyone by considering how we all look at web pages and designing for that. It is true that most users do not read the whole of a web page but they will more likely scan it looking for relevant text to them and their objectives. We can help by laying out our pages with the more important information and links towards the top of the page using contextual links [no "click here" link text], heading, bold [strong], bulleted or numbered lists etc. Each of these should be descriptive so the user can make a judgement on what they need to read and what they do not.

Separating style and content can help you site to be more accessible. This means that the pages style is all contained within the style sheet rather than the html. This will help your pages be ready for the future with the emergence of handheld devices, webTV etc. The main tenet behind this is to layout pages using CSS for all style and layout and remove as much styling from the document as is possible. The idea also encompasses semantic coding, i.e. Using lists for lists of items such as navigational links. For the purposes of web accessibility though you should avoid using styling elements [often referred to as presentational elements] in the page as this may cause accessibility problems.

As mentioned earlier text should be resizable by the user. This is due to users either needing smaller or larger text for it to be readable to them. Within the style sheet text should be sized in %ages, or ems and not in pixels. Pixel sizing is not resizable in Internet Explorer although it is in other browsers. Somewhere around 75% is equivalent to a 10 pixel sizing so a font-size of 75% in the body rule of the style sheet should allow you to have a base to work from across your document.

Forms are one of the main areas that can be helped with regard to accessibility. Forms are usually the main objective of many commercial websites whether they are used for buying products, registering for an event or membership or even contacting a person to ask a question.

Making forms accessible:

• All form items should have prompt text, e.g. if there is a text field requiring a users name it will labeled with prompt text “Name”.
• Use the label tag for prompt text and make sure its for attribute matches the id of the form element it relates to,

e.g. <label for=”name”>Name</label> <input type=”text” id=”name” />

• Position prompt text in its correct position. This is generally held to be to the left or above of input boxes, textareas, and dropdown boxes and to the right of radio buttons and checkboxes. This needs to be positioned correctly within the HTML code before any CSS positioning so it works this way even when CSS is turned off or unavailable.
• If for whatever reason you can not use a label for your form element then use the title attribute of the input tag.
• Grouping items in the form such as all the personal details or questions relating to a particular area can help with accessibility and usability. This is done using the <fieldset> and <legend> tags. A fieldset would wrap the part of the form and legend gives this grouping its heading.
• Grouping dropdown information can also be helpful by using headings within a dropdown box if needed.
• Do not use Javascript to activate a form on clicking a choice in a drop down select box as it is totally inaccessible to screen readers or users with Javascript turned off. Always use a go button or relevant submit button.
• Using Placeholding text. Some older screenreaders do not allow users to edit an input box if it does not have any placeholding text. This is a priority 3 guideline from W3C. However, it is debatable how many people are using such archaic screenreaders so it is debatable whether it is useful. [I tend not to use it as it can often confuse other users from a usability point of view if the form is already filled in].

6) Benefits of Accessibility

The benefits of accessible websites include:

• Reaching the largest possible user base
• Future compatibility with emerging technologies [handheld devices etc]
• Compliance with the law
• Easier management of the site [e.g. changing the style sheet can redesign the whole site. See: www.csszengarden.com for an example of this]
• Making a site accessible automatically helps to optimise the site for Search Engine visibility
• Quicker download times
• Enhanced usability
• Extra press release to let everyone know about your accessible site

7) Acknowledgements

Much of the information for this report was originally published on these three sites:

• WebAIM www.webaim.org
• Webcredible www.webcredible.co.uk
• A List Apart www.alistapart.com
• WAI Web Accessibility Initiative www.w3.org/WAI/
• NCAM http://ncam.wgbh.org/webaccess/

Useful links

Accessibility Guideline checklist – www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html

Download Lynx Text only browser – http://lynx.browser.org

Download Opera – www.opera.com

HTML Element list – www.w3.org/TR/WCAG10-HTML-TECHS/#index-elements

DRC Disability Rights Commision – www.drc-gb.org

RNIB Royal National Istitute for the Blind – www.rnib.org.uk

DDA section 3 – www.drc-gb.org/open4all/law/code.asp

DDA code of practice – www.hmso.gov.uk/si/si2002/20020720.htm