eShop for WordPress is a lightweight ecommerce shopping cart plugin for WordPress. It has been created with accessibility and ease of use in mind. It utilises paypal, but might be expanded for other payment gateways in the future.

Currently this plugin has been tested in version 2.3.3 but should work in 2.2. It may also be usable with extra manual configuration in version 2.0.11.

Features

Since eShop was released, eShop remains one the highest value plug-ins for my WordPress powered site – and one that I retain absolute confidence in. The developers have been continually, and graciously on top of any version upgrades that have come with WordPress, progressively adding improvements — making it a high value plug-in for anyone looking for a well thought-out, highly functional shopping-cart system for their WordPress powered web site.

• Paypal only
• 1 product per page
• Product form will appear on the edit page
• Products can have multiple options
• Upload downloadable products
• Basic Statistics
• Fully searchable
• 3 methods for calculating shipping charges, plus various zone settings via Country or US State
• Parent pages can list featured products, or sub product pages (just like categories with posts)
• Admin has access to an Order handling section
• Automatic emails on successful purchase, with option to send one from the admin order handling section.
• User configurable email templates.
• Configurable Out of Stock message.
• Basic Stock Control
• Automatic creation of required pages such as shopping cart and checkout
• and more!

Installation

Download the plugin, upload to your WordPress plugins directory and activate. Further instructions and help are included.

Changes from 2.3.1 to 2.4.5

(released on 4^th April 2008)

many files have been tweaked. the major change is that the plugin should be compatible with WordPress MU. This version is only compatible for WordPress versions prior to 2.5. No more updates are planned for this version of eShop.

Changes from 2.3.0 to 2.3.1

(released on 4^th March 2008)

There have been numerous bug fixes for this release and many files have been changed. No database amendments have been made although a new table has been created.

The major feature for this release is the creation of a file for upload to Google Base – check the help page for details.

Changes from 2.2.2 to 2.3.0

(released on 24^th January 2008)

Random product listing, and single random product facility added. Fixed a bug with featured, and category listing of products.

Changed files:

• eshop.php
• eshop-plugins/list-subpages-descriptions.php
• eshop-plugins/iinclude_page.php
• files/eshop.css
• eshop_settings.php
• eshop_about.php
• eshop_help.php

Upgrade instructions

The random product is dependant on the Stock Available flag, as such this is now set to no by default. previously it was set to yes, all non single product pages should be amended.

Changes from 2.2.1 to 2.2.2

(released on 1^st December 2007)

• eshop.css admin updated
• eshop_countries.php now able to filter by zone.
• paypal.php – stock control was affecting number of purchases, now fixed.
• checkout.php – updated to fix errors when dealing with US States. Plus added in a few enhancements.(thanks to sbruner for spotting this)
• eshop_help.php – added in a little extra help for sku.
• eshop_install.php – minor alteration.

Changes from 2.2.0 to 2.2.1

(released on 13^th November 2007)

Minor bug fix in paypal.php.

Changes from 2.1.2 to 2.2.0

(released on 13^th November 2007)

• cart-functions.php: fold pages now works correctly, table removed from front end for displaying zones and replaced by a small form, class added to shopping cart form
• cart.php: cart links recoded – div with class older replaced with ul and class ‘continue-proceed’
• eshop_orders.php: minor fix for when first installed, zip code changed to zip/post code, fixed division by 0 error
• eshop_install.php: corrected one country – Sao Tome and Principe
• eshop.php: default level now set to 7 (editor) but can be quickly changed in the script, fixed session destroy to work correctly
• checkout.php: zip code changed to zip/post code, added not applicable as an option to the US States dropdown, cart links recoded – div with class older replaced with ul and class ‘continue-proceed’, major update as per paypal.php
• paypal.php: major update in hidden check – necessary upgrade for all
• paypal.class.php : fixed validity errors, changed redirect page from <h3> to <p><strong> for more portability between themes, altered text to be more user friendly on the redirect page.
• eshop-onload.js: necessary fix due to previous invalid form.
• eshop_help.php: updated with more help!
• files/eshop.css: updated with more styling, but different colour scheme.

Changes from 2.1.1 to 2.1.2

(released on 5^th November 2007) No database changes, small updates to checkout.php and cart-functions.php.

• Fixing US phone numbers
• correcting spelling mistake
• correcting shipping address spurious comma.

My thanks to Daniel Denk for spotting these, and the previous errors.

Changes from 2.1.0 to 2.1.1

(released on 3^rd November 2007) Fixed bug when Stock Control was not used. Only one file affected: eshop-plugins/get-custom.php

Help and Support

Please direct all help and support queries via our forums

Donations

Feeling generous? then please dig deep and donate as much as you can afford!

eShop in the wild

• The Cabinet of Curiosities
• Remote Sensing Tools
• Green Methods
• darmstadt-vor-freu.de
• CMSThemeStore.com

One of the perennial problems of publishing detail of events on a web site is remembering to remove out-dated events on a regular basis. Nothing makes a site look more uncared for than a year old event!

SEM solves this problem by only listing current, or future dated, events so that your site visitors always see an up-to-date page. All a webmaster has to do is pop in every now and then and clear out old material.

SEM also publishes on-demand RSS and Atom news feeds of your event listings to maximise event promotion.

Features

• Run multiple instances of SEM from the one database
• Multiple users allowed – each with their own username and password and, potentially, their own events page.
• Add, edit or delete news items
• Manage users
  • Two levels of users: Standard and Admins
  • Add or delete users
  • Amend an user’s status
  • Protected default Admin – cannot be deleted or downgraded.
  • Change user passwords
• Configurable templates to define how you want your events displayed
• Display event listings anywhere on your site
• Optional display of events on a ‘per user’ basis
• Optional web calendar

Requirements

• PHP 4.x
• MYSQL 3 or higher
• Some CSS/HTML/XHTML knowledge if you want to create your own news template or re-style the interface.

Downloads

• Note: There is a file embedded within this post, please visit this post to download the file.

Support

Available via the Quirm.net forum.

Screenshots

• 

  Sample events list

• 

  Edit display template

• 

  Add an event

• 

  Accessible web calendar

Features

• User definable access keys.
• Ability to decide which links you want the accesskey assigned to.
• Ability to add accesskeys to form labels.
• Clear all option.
• XHTML or HTML options when creating the form.

Download

• Note: There is a file embedded within this post, please visit this post to download the file.

Other Versions

• Juicy Studio

SAXON is an open source online news management system.

Some time ago, I needed a simple, PHP, news management system for a client of mine but I couldn’t find anything that suited. Whilst there are plenty of news management systems out there, most came with emoticons and other bits & pieces that I felt weren’t suitable for a small business web site. Others were overly heavy in features that, frankly, I didn’t need or want.

I wanted an application that was very easy to install and even easier to use. So I built my own.

As I was also looking at ways of generating XML news feeds for syndication, I decided to also build this into SAXON at the same time.

Why is SAXON ‘Accessible’?

I needed an ‘A’ to fit between the ‘S’ and the ‘X’.

Seriously, the interface for SAXON has been built to be as accessible and usable as possible. Providing you don’t go mad when (re)designing its news output template, it should also output highly accessible web pages too. I’ve used it to create compliant XHTML Strict pages that conform to W3C WAI Level ‘AA’ that should be relatively easy for visitors to access when using assistive technology (eg. screen readers, keyboard only navigation etc.). This can only be a Good Thing^tm.

Both SAXON’s output and user interface are currently CSS based – which means that they can be very easily re-configured to suit both authors and audience.

Features

• Run multiple instances of SAXON from the one database
• Multiple users allowed – each with their own username and password and, potentially, their own news page.
• Add, edit or delete news items
• Manage users
  • Two levels of users: Standard and Super Users (Admins)
  • Add or delete users
  • Amend an user’s status (Standard or Super User)
  • Protected default Admin – cannot be deleted or downgraded.
  • Change user passwords
• Configurable templates to define how you want your news displayed
• Display news items anywhere on your site
• Display news on a ‘per user’ basis
• Postdate news articles for later release

Requirements

• PHP 4.3.9 or higher
• MYSQL 3 or higher
• Some CSS/HTML/XHTML knowledge if you want to create your own news template or re-style the interface.

Support

Available via the Quirm.net forum.

Downloads

Screenshots

• 

  Delete a news item

• 

  Edit a news item

• 

  Add A News Item

• 

  Change a user password

If the bigger businesses are going to embrace web accessibility, they’ll need to see clear financial benefits and good returns on their investments. Legal and General’s recent re-design experience provides a solid example of the real business benefits to be gained from developing and accessible web site.

The Legal and General site was re-designed in 2005, with a view to increasing it’s overall accessibility levels following some concern about the old site’s potential for litigation under the UK Disability Discrimination Act. One year following the site’s relaunch, the following ‘indirect’ benefits were noted:

• A 30% increase in natural search-engine traffic
• A significant improvement in Google rankings for all target keywords
• 75% reduction in time for pages to load
• Cross browser-compatibility increased (not a single complaint since the redesign)
• Site now accessible to mobile devices
• Time to manage content reduced from average of five days to 0.5 days per job
• 95% increase in visitors getting a life insurance quote
• 90% increase in Life insurance sales online
• Savings of £200K annually on site maintenance
• 100% return on investment in less than 12 months.

Clear evidence from a competitive company that increasing overall web accessibility can result in significant business and financial benefits.

These are not complete guidelines, but should be viewed as “quick ‘n’ dirty” tests for some of the checkpoints from the Web Content Accessibility Guidelines (WCAG) 1.0.

WCAG 1.0 supporting documents include a simplified Checklist and a detailed document describing techniques for implementing the Guidelines that includes references to both HTML techniques and CSS techniques. There is also a multimedia curriculum presentation which explains how to use the guidelines but it should be noted that this presentation is dated March 2000 and, consequently, maybe be somewhat outdated in regard to current browser technology.

The Checks

Images & animations: Use the alt attribute to describe the function of each visual.

One method that has been previously described for checking alt text is to place the cursor over an image, or animation and look for a small tooltip window displaying the contents of the alt attribute. Unfortunately, this only works within Internet Explorer which, incorrectly, displays alt text in this fashion. One, cross-browser, method for checking that alt text is, not only present on appropriate image elements, but is also suitably descriptive, is to check a page within a graphical browser with image display disabled. Even better, try looking at the page using a text-only browser such as Lynx.

If you are using image buttons for navigation, is it still possible to navigate the page, or site, effectively within a text-only browser? If images display important additional information, is that information also available within the alt text?

Finally, imagine reading the page aloud over the telephone. What would you say, upon encountering an image, if you wanted to convey the correct information to the listener?

Image maps. Use the client-side map and text for hotspots.

If you are using image maps, try to use client-side maps rather than server-side maps. As well as providing a description of a map using the alt attribute, ensure that you also provide text links for each hot spot within the map to ensure that users of non-graphical browsers etc. can still navigate effectively.

Multimedia. Provide captioning and transcripts of audio, and descriptions of video.

If you are making use of videos, have you provided alternative text which is synchronised to the video in order to obtain a ‘captioning’ effect? Do the captions convey the same basic information (where possible) as the video itself? Disable the video display. Can you still follow the presentation?

Are you using audio to convey information? If so, turn your speakers off and check that the text transcripts of your audio information convey the same basic information. Wherever possible, use simple language for audio transcripts as many deaf users will, by default, use sign language as their primary method of communication with spoken/written language as a second language.

Hypertext links. Use text that makes sense when read out of context. For example, avoid click here.

Screen reader users may jump from link to link within a given document without reading the intervening text. This is broadly analogous to the way in which sighted users often “scan” large documents looking for keywords or phrases before reading the surrounding text properly. In such a situation, link text along the lines of More information may be meaningless as there is no indication of what information is being referred to. Try reading link text out aloud without referring to the accompanying context. Does it make sense? Would a user be able to broadly understand where such a link was leading to? If not, amend the link text so that it reads, for example, More information on our full product range

Page organisation. Use headings, lists, and consistent structure. Use CSS for layout and style where possible.

View your page in a graphical browser with all styling disabled or using a text-only browser. Is the page organisation still clear? Can lists be easily identified? Does the structure of pages vary from one to another? Using a consistent structure within all pages on a site increases the chances that information can be located easily or avoided when necessary. Are your navigation bars, or menus, in the same place on every page? Are page headers and footers structured in a similar manner across the site? Using a random page from your site, is it possible to accurately predict where the main page content will be on any other page before you view it?

Graphs & charts. Summarise or use the longdesc attribute.

Graphs and charts should be treated in a similar manner to other graphics but may require more textual information than is appropriate with a simple photograph. Although WCAG 1.0 mentions the longdesc attribute, browser support for longdesc is currently limited. Try looking at the page using a text-only browser. Does the alt text convey enough information for those users who may be unable to see the chart or graph? If not, consider adding descriptions of such images on a separate page and provide a text link to the description near the graph, or chart, itself.

Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported.

Do not rely on client-side technology. Not all users have access to javascript, for example. Does your page still function effectively with javascript switched off? If you’re making use of Flash, test the page out in a browser that doesn’t have the appropriate plug-in. Is the information within the page still accessible? As above, using a text-only browser is an excellent way of checking for these accessibility issues but, be warned, incorporating a no-script alternative that simply suggests that users download the latest plug-in etc, is not an appropriate solution.

Frames. Use the noframes element and meaningful titles.

Whilst the number of older browsers that cannot access frames has undoubtedly fallen, it cannot be assumed that users will always arrive at a framed site by means of its frameset page. Try viewing one of the underlying framed pages without accessing the frameset. Can users still navigate to other areas of the site? Use the no-frames element to provide an alternative navigation mechanisem for those few users who are still using technologies that cannot access frames.

Tables. Make line-by-line reading sensible. Summarise!

Are you using tables? Do they contain data or are they used for layout? If possible, consider CSS for layout instead. Use the caption element to provide short summaries of tabulated data. Some older screen readers access tabulated information by column rather than by row, so ensure that the content still makes sense when read aloud on a column-by-column basis. W3C also provides a table lineariser that can be useful in this respect.

Check your work. Validate. Use tools, checklist, and guidelines.

One of the most basic requirements of an accessible page is that it has been built using compliant HTML techniques. If your page does not validate according to its DOCTYPE, then it may contain elements that cannot be accessed by a range of assistive technologies. Single pages can be validated online using W3C‘s HTML Validation Service. Multiple pages, and even entire sites (up to 100 pages), can also be validated using the Web Design Group’s Validation Service but be warned that some differences have been noticed between the two parsing engines when validating custom DTDs.

Basic online, automated, accessibility checks can be made using Hisoftware’s Cynthia Says portal but this should be supported by manual reference to the WCAG Guidelines.

The Legal Case

Firstly there is the legal responsibility embodied in the Disability Discrimination Act 1995 (‘the Act’) that places a responsibility upon providers to ensure that disabled individuals have effective access to services and information.

The Act affects every service provider in the UK whether in the private, public or voluntary sectors and covers “access to and use of information only services”.

For example, under the provisions section 19 of the Act, it is unlawful for a provider of services to discriminate against a disabled person:

(a) in refusing to provide, or deliberately not providing, to the disabled person any service which he provides, or is prepared to provide, to members of the public;

Section 19(3) goes on to provide examples of the services. Sub-section (b) applies to “access to and use of means of communications” and sub-section (c) applies to “access to and use of information services”.

Both of these sub-sections clearly apply to the design and functioning of a web site on the Internet.

Statutory codes of practice are issued by the Disability Rights Commission (DRC) an independent body empowered by the Government to help secure civil rights for disabled people.

The DRC can also fund representation for individuals, where it believes discrimination has occurred and, under the provisions of the Disability Rights Commission Act 1999, it has the power to instigate formal investigations into sectors where it believes that discrimination is taking place.

On 27th March 2003, the DRC began a formal investigation into the accessibility levels offered by 1000 web sites. Whilst the final report from this investigation has yet to be released, it is expected to confirm that the vast majority of web sites fail to provide even the most minimal accessibility provision.

The Technical Issues

For a start, the Act does not include any hard and fast rules for acceptable levels of web accessibility.

Not surprisingly, there are web markup standards that can go a long way to ensuring that sites are developed to serve the largest possible audience using the broadest range of hardware and software platforms, and with the needs of disabled users taken into consideration. These, internationally accepted, standards are produced, and maintained, by the W3C Consortium who also provide validation tools to assist designers in creating markup compliant web sites.

Validating sites against the W3C standards can go a long way towards achieving minimal accessibility levels.

However, the World Wide Web Consortium (W3C) has also compiled a set of guidelines regarding web accessibility levels. Known as the Web Content Accessibility Guidelines (WCAG)1.0, they have been produced under the auspices of the W3C’s Web Accessibility Initiative (WAI) and compliance with them is an obvious demonstration that web accessibility is being taken seriously.
The WCAG guidelines are divided into three Priorities, or Levels:

• Priority 1 (Level A): This is considered mandatory for all web sites.
• Priority 2 (Level AA): Web sites should actively work towards this level, as part of an ongoing accessibility policy.
• Priority 3 (Level AAA): Some web sites may consider compliance with this level in order to maximise site accessibility.

Service providers should, therefore, ensure that their sites comply with Priority 1 (Level A) and seriously consider working towards Priority 2 (Level AA) and possibly even Priority 3 (Level AAA).

Whilst there are some parsing engines that can assess the general accessibility levels of a given web page (e.g. Watchtower’s “Bobby” and the Outreach Project “Cynthia Says”), they can, at best, only give an accessibility estimate that should then be verified by an independent expert.

Remember – the duty is a continuing one as ongoing developments, especially in the field of IT adaptive technology, may improve potential web accessibility. Therefore it may be advisable to adopt a site accessibility policy and to review both this, and the site’s accessibility levels, on a regular basis.

The Business Case

There are approximately 10.5 million people with disabilities in the UK at present, who have a cumulative disposable income of over £50 billion. How many organisations would knowingly disregard such a considerable sector of their potential customer base?

But, most significantly, the effective implementation of good practice in the design of an IT resource or website benefits everyone – whether they have special requirements of access or not. This is because the overall design is concerned with the best implementation of a wide range of elements including colour, graphics, text, multi-media, frames, and dynamic elements. It addresses the many inconsistencies that can arise in the overall experience of each user.

When such a holistic approach is applied, the result is a resource that is easy to use for all – regardless of what technology, specialist or otherwise, is being used to access it.

Web accessibility is specifically aimed at opening up resources on the World Wide Web to allow for the participation of people with disabilities.

Web Accessibility

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
(Tim Berners-Lee, W3C Director and inventor of the World Wide Web)

For those unfamiliar with web accessibility issues, consider the fact that many of your site visitors may be operating in contexts very different from those you might expect or assume:

• They may not be able to see, hear, move, or may not be able to process some types of information easily or at all.
• They may have difficulty reading or comprehending text.
• They may not have, or be able, to use a keyboard or mouse.
• They may have a text-only screen, a small screen, or a slow Internet connection.
• They may not speak or understand fluently the language in which the document is written.
• They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system.
• They may be unable to see colours at all. Many people (about 8% of men and 0.5% of women) are unable to distinguish certain colours, such as red and green.

However, many web sites exist that have completely ignored published web standards and sport complex screen layouts without considering the accessibility implications. These sites are aimed at impressing and engaging the mainstream, non-disabled, visitor but they may confuse and alienate people with visual or cognitive impairments. New developments may be inaccessible to a wide range of web users, either because their hardware and software cannot support the new features, or because the feature was not designed with universal accessibility in mind.

For example:

• Will a web page offer the same access to information if viewed in a text-only browser compared to a graphical browser?
• Does a text-based page use simple language that is understandable by those with cognitive difficulties?
• What does an informational page supply in the way of graphical assistance for people with reading difficulties?
• Are online forms accessible to users who cannot use a mouse or keyboard?

Nor is it safe to assume that web site visitors will be using “standard technologies”.

On the Web, there is no such thing as a “standard user” let alone a “standard technology”, yet, despite this, too many sites sport the disclaimer:

This site is best viewed using…

If you intend to use such a disclaimer, it should at least be honest and say:

This site is best viewed on my system and my monitor at my house.

For, if you haven’t incorporated a basic level of accessibility into your site design, that is about all you can claim with any conviction.