Website Accessibility: Why Bother?

An accessible website is the one that anyone can access and can easily use, including those with disabilities. It would be fair to say that while most business want their website to be ‘user friendly’. Accessibility is not at the top of their agenda. In all of the years I have been developing business websites, no company has ever requested accessibility as part of their website brief. It is often part of the brief for public sector websites but even then this is usually a result of a legal requirement or the aim of achieving an award.
Making a website accessible can mean extra effort on behalf of the web designer and the organisation behind the site. To achieve great accessibility though, all types of end user need to be considered and catered for, from those with visual impairments who may use a screen reader to read your website’s text, to users with motor skill difficulties and intellectual disabilities. This can add extra cost to the project which many businesses are not willing to pay especially since the return on investment may not be immediately obvious. Given the extra cost and effort…

Why should a business consider having accessibility as part of their website brief?

1. If your business has a social conscious and states that it cares about it’s social responsibility, then incorporating some accessible features is worth considering. These can then be listed in an accessibility statement on your website.
2. You may think that your target customers do not have disabilities but when you think of all of the different types of disability then chances are that a certain percentage of them do. For example, most of them will not be totally blind, but many of your customers may have poor vision or be colour blind and will not want to work with you if they can’t use your website.
3. A website designed for people with disabilities will also be very accessible to everyone else, allowing your site to reach a wider audience.
4. Many accessibility features also have good cross over with other important considerations like cross browser and cross device compatibility. For example many experts don’t recommend the use of Flash, as screen readers can’t read the content in a Flash site and people with certain disabilities can find moving content hard to focus on or interpret. Similarly a Flash site won’t display at all on the iPhone or iPad so by meeting this accessibility requirement you are making a site that will ultimately be seen by more people. I have come across a few sites lately that because they are built entirely in Flash don’t display at all on the iPhone or iPad.
5. Accessibility forces you to think about the end user. Often business managers want to include a particular item on their website such as animation or a video because they think it will look impressive or because the competition has it on their website. If they have to consider ‘Is that Accessible?’ it forces them to stop and think about how the end user will perceive the content. If it does not enhance the site for the end user then why would you add it to your website?

If accessibility is part of your website brief from the beginning then it is a lot easier and cost effective to achieve than trying to make an existing site accessible.
In website accessibility – Part 2, I will guide you through some of the features you can add to your site to ensure it is accessible, as well as giving tips on how you can check the accessibility of your website. In the meantime The Centre For Excellence in Universal Design is a great resource.

Securing your website by handling errors

When a website is being attacked by a hacker, one attack approach is to cause the website to fail in some manner. The thinking behind this approach is to use the error message to gain ‘inside’ information about the website. With this information, the attacker is planning to better organise their attacks on the website.

Error messages can provide detailed information and in the wrong hands…

Error messages, by default, are designed to provide all the necessary information to help resolve the error. However, in the wrong hands, this type of content can provide ‘valuable’ information on how the website operates in addition to access to privacy related information on customers and transactions.
Using this sample database error message from a blog by Securiteam on sql injection as an example; by causing the error, a hacker can see that the first table name in the database  is called ‘admin_login’.

Microsoft OLE DB Provider for ODBC Drivers error ’80040e07′
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘admin_login’ to a column of data type int.
/index.asp, line 5

With a subsequent query, it can be possible to start to extract the column names of this table, as the example shows the column name ‘login_id’.

Microsoft OLE DB Provider for ODBC Drivers error ’80040e07′
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘login_id’ to a column of data type int.
/index.asp, line 5

In this example, with the names of the table and columns, it would be possible for a hacker to easily get access to login ids and passwords for the website.

The best defence is…

The best place to start to ensure that any error messages are handled securely is when the website is being designed and developed. As the website requirements are being discussed, any related exceptions that may cause an error should also be documented.
For example,  I discussed the importance of data validation to ensure that no inappropriate data inputs could be used to attack a website. In such a scenario, rather than having the website failing and producing an internal error message such as in the above example, a user friendly message should be displayed, indicating the expected format and length of input.

Test and test again…

During the testing of the website, security testing using different attack scenarios should be completed to test the strength of your website by simulating a series of different attack methods and reviewing the results to detect and correct any weaknesses. These penetration testing scenarios should cover both typical attack methods, along with any unexpected attacks or errors. To ensure that the ‘unexpected’ errors are tested, brainstorming sessions involving developers and business owners who know their user community will be necessary, where the focus is on uncovering any unusual and unexpected user actions.

Fail safe is key

When designing the website, an important principle to include is to ensure that if an error occurs, sufficient information is provided to guide the user with no information on any server or software related topics (i.e. the website has ‘failed’ into a safe mode). In addition, all errors should be handled in a structured manner, so that irrespective where an error occurs on a website, the response is the same and managed in a consistent manner.

Business logic not the code can be the problem

When reviewing your website for potential weaknesses, it’s more important to assess the logic of your workflows, as the logic is the foundation for your code. The logic is driven by the business rules of the functions being provided by the website. Two examples of possible mis-use of logic include;

• The provision of a password reminder function to assist legitimate users who may have forgotten their passwords. To ensure that such a function is not abused by a hacker, a captcha function can be included to prevent any brute force attacks.
• The assumption that a withdrawal amount entered into an online banking service will be positive, thus leaving the possibility that a negative amount will trigger a credit to a person’s account. A data validation check on the entered value should resolve this potential weakness

As with all security principles, if time and effort is put in at the early stages of a website or application, it provides the foundation for a secure website. So in the enthusiasm to get your website live, taking some time at the start to ensure that any potential weaknesses are removed and that any unexpected errors are managed in a fail-safe manner is well worth the investment.

Upgrade magento 1.7 to 1.8 the accordion of the checkout page step 5 payment information doesn’t work anymore

Since I have upgrade magento 1.7 to 1.8 the accordion of the checkout page doesn’t work anymore whatever the theme I choose. I tried to fix the problem, no success. What can I do to fix it ?

I finaly found the problem. Go to “/app/design/frontend/base/default/template/checkout/onepage/payment.phtm” open it, line 36, and change :

<fieldset>
        <?php echo $this->getChildHtml('methods') ?></fieldset>

To :

<fieldset id="checkout-payment-method-load">
        <?php echo $this->getChildHtml('methods') ?></fieldset>
Works great for me its been bugging me for a few days trying to sort it out.