Neuromedia

Responsive Web Design

Neuromedia — Sat, 17 Dec 2011 12:18:22 +0000

What is responsive web design?

The term Responsive Web Design was coined by web designer Ethan Marcotte (http://unstoppablerobotninja.com/) in an article on A list Apart (http://www.alistapart.com), and it basically amounts to a new way of designing and developing websites to ensure that the design is optimized for all possible types of browser window displays, resolutions, sizes and shapes as well across browsing platforms, using a combination of flexible or fluid grids, flexible images and CSS media queries. Marcotte qualified his definition by saying that:

“A responsive design is composed of three distinct parts:

1. A flexible grid.
2. Flexible images. Or more specifically, images that work in a flexible context (whether fluid themselves, or perhaps controlled via overflow).
3. CSS3 Media queries, which optimize the design for different viewing contexts, and spot-fix bugs that occur at different resolution ranges.”

With the advent of smartphones, e-readers, netbooks and tablets, the number of screen-sizes and devices our websites are served to and displayed on are increasing exponentially as are browsing methods such as the use of touchscreens, game controllers, mice and keyboards. Thus as technology grows and changes so must our scope as designers. Responsive web design means a whole new way of working when designing, including using new features of CSS3 and tools like Javascript and PHP to ensure that websites are completely scalable from one device to another and from portrait to landscape on devices that offer both. For example, instead of using absolute values, scalable web design means using percentages and em’s.

Clients will obviously want designs that are accessible across a wide range of devices, and one option up until now has been to design separate websites for separate devices. While this still has its place in some scenarios, responsive web design offers an alternative to this.

Some of the basic tools and techniques needed to accomplish the design of a responsive website will now be examined more closely.

2. Features of responsive web design

Responsive Typography

Responsive typography means that your typography and its attributes scale to be optimally legible on the screen they are being read on and remain correctly positioned within the design structure. This means that when coding, you will use em’s and percentages instead of absolute pixel or point sizes so that fonts remain resolution independant. Using different stylesheets or CSS3 media queries, text can be altered to display legibly for the device the user is reading on.

There are also external tools such as Lettering.js (http://letteringjs.com/) which grant designers much greater control over their web typography (letter spacing, leading and kerning) by making font sizes flexible and FitText (http://fittextjs.com/) which makes heading sizes relative to the width of the parent containers and display devices, rather than relative to the other text, so that they fill space as they should.

Flexible images

As the name suggests, flexible images are images that scale with the size of the device screen. There are several ways to accomplish flexible images sizing, some of which are simple but more resource-heavy and others more complex but lightweight in terms of image load times.

Using just HTML and CSS, the width and height of an image can be set using the CSS max-width property. When set to 100%, images will be loaded to the site at their original sizes and then resized by the browser to fit the containers they are in (which with media queries will change depending on the device they are viewed on). The downside to this is that for smaller devices like mobiles, page load times can be unnecessarily slowed down by an image-heavy page or large images.

Another option is to crop images using the overflow: hidden CSS property, meaning only selected portions of an image will display on smaller screens.

Moving on to more complex methods of display, scripts like Javascript and PHP can be used to select from many versions of an image on a server and display them to the site depending on screen size and resolution.

Responsive web page layouts

The use of flexible grids is paramount to responsive web design. The flexible grid builds on the idea of liquid layouts and basically means that designers must stop using pixel values to define elements and start using percentages – all layout elements must be calculated as percentages relative to their parent containers.

CSS3 media queries are the crux of responsive web design and responsive web page layouts. They are applied to toggle the website layout width and height in response to the width and height of the user device and allow the designer to code any styling element to display differently depending on the size of the screen width or resolution it will appear on.

This means that a 3-column desktop website can become a single column mobile website by changing the layout and positioning of column elements using the media query inside a stylesheet or by linking to a completely separate stylesheet in the link tag, for example:

This would link any device with a screen and display size of less than 480px to a stylesheet called example.css, and bypass the main website stylesheet altogether.

Testing and cross-browser support

Naturally, it is vital to test your websites across all the major browsers, both pc and mobile as well as testing them on as many devices as possible. Software applications such as Adobe Device Central are very useful for testing like this as it has a large library of device interfaces on which to display your design. Free tools like Web Developer (http://chrispederick.com/work/web-developer/) are also very useful for web development testing as they allow you to view your designs in many different window sizes.

When trying to be as wide-reaching as possible, there will always be gaps and shortfalls where things do not work across all the mediums you are trying to reach. In some cases, Javascript or other scripting fixes can be applied to compensate for browser incompatibilities, especially for earlier versions if IE or mobile devices which don’t support many of the newer features of CSS and HTML5 like the media query.

In some circles, these is a growing de-emphasis on the necessity for a website to look identical from browser to browser providing the site displays in a functional and aesthetically pleasing way. Naturally, those users with browsers that support features such as HTML5 and CSS3 will have a richer experience, but as long as the content of the site is accessible to all, the exhaustive amounts of time that can be wasted trying to get the site looking identical across all browsers can be bypassed by accepting the differences as they are.

3. Conclusions

Pros

Responsive web design is a good way to “future proof” websites against the ever-changing nature of the technology we use to view the web with. Its nature makes it adaptive and thus longer lasting in terms of the life-span of the website. It eliminates the need for different designs for different devices and thus saves time.

As opposed to a simple static design, a responsive design improves overall user experience by offering the user something he can view correctly over all his various internet access platforms, and possibly even makes the site accessible to more users that it would have been otherwise as so many users (especially in this country) have mobile internet access, but no desktop access.

It forces designers to think outside of the standard-static-website box, (which we should have been doing for a while now anyway) and expand the scope of our designs.

Cons

Different devices have different capabilities, and responsive web design on the whole does not seem engineered to design to the lowest common denominator (i.e. older, slower mobile devices).

CSS Media queries are applied only after all content has been downloaded, including images markup, scripts, etc, meaning that even if the display looks good across all devices, there will be bandwidth problems for mobiles especially in cases of image-rich sites. Only if smaller images are served to the mobile separately using scripting, will this problem be overcome.

In addition, CSS3 Media queries are not supported by most mobile handsets or by older web browsers, meaning that complex javascript workarounds may be necessary.

Responsive web design has been called a fad and a quick fix by some, who are in favour of device-specific development, saying that it is not possible to downscale a desktop website effectively and still get a pleasing outcome. Certainly, responsive design cannot make a website all things to all people and there is only so much that media queries can achieve. Due to the sheer number of different devices out there, a site is never going to look perfect on all of them.

The future

There is a place for responsive web design out there, but one needs to look very carefully at what the website is trying to achieve. Simply put, responsive web design is appropriate for certain websites and not appropriate for others.

For any standard run-of-the-mill website, having a responsive site is a great idea, but a before committing to the design, a detailed analysis of who visits the site, from where (what devices) and why, will help the designer decide whether going the responsive route is best, or whether designing a dedicated mobile site is a better idea. At the end of the day, the user decides the role responsive web design will play.

When a mobile user is after content and nothing much else, for example on a news website, it makes more sense to build a separate mobile site mainly stripped of images, giving it a better load time, and perhaps use responsive web design to tackle desktop and tablet devices.

In addition, in the case of large application websites like Facebook, it would seem evident that mobile apps are more appropriate than a resized version of the main site because the user can find and access what they want instantly instead of having to navigate around. The same would apply to image-rich consumer websites where the user wants limited and specific data that is easy to find. Instead of having him scroll around looking for things, building an appropriate mobile interface would probably be a better route.

I tend to agree with Kayla Knight from Smashing Magazine, that responsive web design is not the be-all and end-all answer to mobile and device web design, it is merely a concept and one of several options, which, “when implemented correctly can improve the user experience as technology evolves.” It is certainly more inclusive than the alternatives and will reach a wider range of web users. It is brilliant that using CSS3 and HTML 5 we can now build a site that will port from the oldest pc to the newest mobile device in a way that wasn’t possible 5 years ago, but I believe that mobile-specific sites or alternatively mobile apps, will also always have their place.

References

Ethan Marcotte clarifies his definition of “Responsive Web Design”. June 23 2011. David Cochran .09 September 2011. http://alittlecode.com/ethan-marcotte-clarifies-his-definition-of-responsive-web-design

10 Excellent Tools for Responsive Web Design. Aug 3 2011 . Jason Gross. 09 September 2011. http://sixrevisions.com/tools/responsive-web-design/

Fit To Scale. May 10th, 2011. Trent Walton. 13 September 2011. http://trentwalton.com/2011/05/10/fit-to-scale/

Responsive Web Design: What It Is and How To Use It .January 12th, 2011. Kayla Knight. September 13^th 2011. http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/

Responsive Web Design. May 25, 2010. Ethan Marcotte. September 08 2011. http://www.alistapart.com/articles/responsive-web-design/

Understanding the Elements of Responsive Web Design. March 14, 2011. Jason Gross. 09 September 2011. http://sixrevisions.com/web_design/understanding-the-elements-of-responsive-web-design/

Responsive Web Design Techniques, Tools and Design Strategies July 22nd, 2011. Smashing Editorial. 09 September 2011. http://www.smashingmagazine.com/2011/07/22/responsive-web-design-techniques-tools-and-design-strategies/

Foreground images that scale with the layout. April 24, 2009. Zoe Mickley Gillenwater. 13 September 2011. http://zomigi.com/blog/foreground-images-that-scale-with-the-layout/

Responsive Web Design – Stop and Think. 26 August 2011. Anthony Grace. http://www.codersbarn.com/post/2011/08/26/Responsive-Web-Design-Stop-and-Think.aspx

Responsive Web Design, most complete guide. September 13th, 2011. WebDesignShock. 14 September 2011. http://www.webdesignshock.com/responsive-web-design/

11 reasons why Responsive Design isn’t that cool! August 24th, 2011. WebDesignShock. 14 September 2011. http://www.webdesignshock.com/responsive-design-problems/

5 Common PHP security issues and how to address them

Neuromedia — Sat, 17 Dec 2011 12:04:54 +0000

PHP has developed into the most popular language for programming on the web, but like all languages, it has its weaknesses. Described below are some of the more common areas of vulnerability found in PHP web applications and suggestions on how they can be managed and prevented.

1. SQL injection

What is it?

One of the most common forms of hacking, it is an attack specifically targeted at database-driven web applications or websites which link to and interact with databases. A SQL injection attack is a type of code injection where the attacker exploits vulnerabilities in the website’s security measures in order to send special SQL queries to the database that can modify it, delete data and tables within it or delete the whole database in the worst case.

Attacks occur when the developer has failed to build in any checking or data validation functionality for the areas of the site where data from external sources can be inserted into the site. Attackers will append their own SQL statements into unprotected SQL queries that utilise data submitted by a user to look up something in the database. Attack entry points can include search boxes, login forms, email query forms, signup boxes, etc.

Where user input is allowed to directly interact with building the SQL statement which interacts with the database, with no form of filtering, an attacker can easily control the statement that is executed.

So for example, an unprotected statement would be:

$query = “SELECT * FROM users WHERE username = ‘niki’”;

A SQL injection query will result in the following attempt:

$query = “SELECT * FROM users WHERE username = ” or ’1=1′”;

The result returned here would always be true, and thus the contents of the entire table users would be displayed.

What are the implications?

Attackers can gain access to all the information in the database including names, usernames, passwords and other sensitive information.

Tables and information in the databases can be altered, created or dropped which could obviously have dire effects on the front end of the website.

The entire website can be defaced if the hacker gains admin privileges.

How can it be prevented?

Data must be verified, validated and cleaned up before it can enter the application – all input received must be sanitised.
Sensitive information such as passwords should be encrypted using SHA or SHA1
Any technical information must be removed from error messages which can sometimes contain technical details that might reveal security vulnerabilities to an attacker. Attackers will specifically look to error messages to get information such as database names, table name and usernames. Error messages can be disabled or you can create your own custom error messages.
Limit the permissions granted on the database – the fewer permissions, the lower chance of attack – for example, people accessing the front end of a website through a signin need far fewer permissions than someone accessing the backend CMS.
The best way to santise data is to ‘escape’ any characters in a string entered into the website which may have special meaning in MYSQL and therefore potentially be dangerous. When a character is escaped it is effectively ignored by the database and made ineffective in a query. The standard character used by PHP and MY SQL to escape characters is the backslash (). This technique is used in several functions in PHP which exist to protect and sanitise data.

The mysql_real_escape_string escapes any special characters in a string and replaces characters that have a special meaning in MySQL with an escape sequence for use in an SQL statement - the function adds backslashes to the following characters – n, r, x00, x1a, ’, ” . Note: this function is for PHP versions 4.3.0 and above. Another (older) option to use is addslashes.

There is a function called magic_quotes_gpc – when this on, then all the POST, GET, COOKIE data is escaped automatically, but this function is now deprecated.

You can take your protection one step further and prevent words such as ‘update’, ‘insert’, ‘drop’, and ‘union’ from being added to the database (these all being words which can alter tables and databases), but this may affect valid queries on your database.

One way to bypass the problem if you are an inexperienced developer is to use a pre-existing framework such as CakePHP (http://cakephp.org/) or a prebuilt CMS such as WordPress or Drupal, which have built-in routines and security measures to prevent SQL injection.

2. Cross Site Scripting (XSS)

What is it?

Probably the most common form of hacking, this is where a hacker uses a legitimate website’s vulnerability to force that website to do certain things. The malicious user embeds client side scripting commands (often JavaScript or HTML but can be, VBScript, ActiveX or Flash) in order to collect session information and cookies and use these to hijack sessions and further attack the site. The inserted code can be used in several ways, including to steal other user’s private information or to deface the site by rewriting the content of the HTML pages.

Forums and message boards are especially vulnerable to this type of attack. An example would be: a hacker will create his own malicious website and inject hyperlinks onto the legitimate site – hyperlinks and email links are often posted in forums. When a user clicks the hyperlink, the vulnerability in the legitimate website allows the injection of malicious code into that site, and from there onto the user’s machine via their browser.

What are the implications?

Once injected, the malicious code is stored in the website’s database and when it is fetched and displayed to the visitor, the resultant page can be distorted – code can also be run which steals cookies or sends information such as the session ID to a malicious third-party site.

If JavaScript is injected into the HTML source, it can also be used for simple things such as redirecting a user to a spam website or in a more sophisticated attack such as keylogging - sending the user’s keystrokes (e.g. passwords) to an external database.

XSS can be used for user-account hijacking, changing user’s settings and stealing their confidential information. As mentioned, sessions and cookies can be hijacked or stolen, altered and reused. New uses are continuously being found for XSS by hackers, according to Cgisecurity.com.

A method used in conjunction with XSS is known as Cross-Site Request forgery. This is where the malicious code tricks the user’s browser to send requests under the guise of the legitimate user, so for example, it could use a user’s online email account to automatically send out emails such as spam mail.

How can it be prevented?

As with SQL injection, the best way to prevent XSS is to use escape functions. Specifically to escape characters that comprise HTML and JavaScript syntax like ‘<’ and ‘>’ or to convert them into HTML entities, (so < would become < for example).

The htmlspecialchars () function indentifies any output you don’t want to be HTML output and converts it into plain HTML entites, so for example: ‘&’ becomes ‘&’ and ‘”‘ (double quote) becomes ‘"’

The htmlentities() function can also be used and it similarly converts all applicable characters to HTML entities.

In forum websites, where legitimate users will want to post HTML such as links, an alternative syntax such as bbcodes (which is very common on forums) can be used to overcome the escaping of HTML characters.

The most important way prevent XSS is to rigorously test the site before launching it.

3. Remote file inclusion and remote code execution

What is it?

This is a security breach which allows an unknown or malicious party to run code on your web server or client side and can lead to several further types of hacking.

Remote file inclusion is caused by a site vulnerability which allows an attacker to deploy a malicious file onto the web server. This can be caused by improper use of the include() and require() functions when the register_globals directive is on(allowing the user to initialise variables remotely). The register_globals directive is the setting which controls the availability of superglobal variables (e.g. form data, cookie data). If the directive is on, an uninitialized variable can be used to include unwanted and malicious files from remote locations. If the allow_url_fopen is enabled in php.ini, remote files can be uploaded to the website’s server via HTTP or FTP from a remote location.

What are the implications?

Remote file inclusions can lead to things such as data theft, remote code execution on the server, code execution on the client-side leading to problems such as cross site scripting and denial of service (DoS).

Remote code execution on the server side means that if the file that the attacker has included is a shell (a file which can affect the operating system) the attacker can run system-level code on the server and use this to retrieve or alter data on that server or hack the end-user’s terminal.

Client side remote code execution can lead to cross site scripting, as discussed in the previous section of this essay.

Denial of Service prevents the users of a site from being able to access that site by preventing the web servers from serving web pages or overloading the server with requests, slowing it down and basically making the site inaccessible.

How can it be prevented?

The register_globals directive should always be OFF – in later versions of PHP, it is off by default, but one should always check that.

If the register_globals directive has to be set to ON for some reason, all variables must be correctly initialised.

There are other php directives can be used to prevent remote file inclusion, which include:

allow_url_fopen (set to on by default) - controls whether remote files should be includable and should be turned to OFF.
allow_url_include (set to off by default) - controls whether the include(), include_once(), require() and require_once() commands are able to include remote files into the code.
Enabling safe_mode which forces PHP to test of user ID permissions before opening files.

Additional precautions include always validating user input and being very careful with any data retrieved from remote servers or locations. The simplest way to stop it is to just ensure that all include files are locally hosted and to never accept files from anywhere else unless absolutely necessary.

Restricting user privileges to an absolute minimum can also help prevent this.

4. Session and cookie hacking

What is it?

The hacking of sessions and cookies cannot breach the database or the web application itself, but can compromise user accounts.

A session is an entity triggered when a user initiates contact with a server and consists of a period of interaction between the user and the web application which may be authenticated using security measures such as a password and username. During this session, the web application will store a file or cookie on the user’s machine (browser) which will contain information about the session such as the user’s preferences, authentication data or for example, shopping cart information.

XSS, discussed previously is the most common way in which hackers can steal cookies. Another risk is when hosting is shared by multiple people and session ID’s are stored in a shared /tmp directory, meaning anyone can access and read them.

What are the implications?

When a user logs in to a site, a session ID is created for the user, and a session hacker will try to obtain the legitimate user’s session ID and use the information. When the hacker steals and tries to reuse a session ID, it is known as session fixation, and it could basically allow the hacker to login as an authentic user and cause damage or alter the user’s account – this is particularly dangerous when the user is an administrator or someone whose account contains sensitive data.

How can it be prevented?

Session ID’s should be changed often, therefore the session_regenerate_id() function should be used every time the user logs in, assigning them a fresh ID – this prevents hackers from setting session ID’s prior to login.

Risks can be mitigated by revalidating a user who is about to perform sensitive tasks such as resetting their password (i.e. by making them re-enter their old password). Also, if a password is to be stored in a session variable, it must be encrypted (using the sha1() function), but most sources suggest it is best not to store a password in a session variable at all.

In cases of shared hosting, you can redirect the data to be saved in a location only you can access by using the session.save_path directive.

Using an SSL or secured connection if your web application is handling sensitive information such as credit card numbers can also prevent session and cookie hacking.

5. Directory traversal (aka path traversal)

What is it?

This is a method of exploiting web applications by accessing files beyond the document root directory allowing the hacker to view restricted files and folder and interact with the server by executing commands. The attack usually occurs through a web browser and is accomplished by the attacker entering a URL into the address bar which will take him out of the root directory and into the main server directories – this would generally take some guesswork on the part of the hacker, but can actually be pretty easily done. It can also be achieved through input portals on the front end of the web application.

What are the implications?

Once inside the server’s system files and folders, the hacker has access to all sorts of information and sensitive data including application source code, configuration and critical system files. They may even add or delete files and play havoc with the server’s setup.

How can it be prevented?

The simplest answer is that you should sanitise and validate all user input correctly by removing all suspect data and filtering out meta characters.

Another precaution to take is to never store sensitive configuration files inside the web root.

Wikidpedia suggests that if a suspect request to a file is made, the full filepath should be built up, if it exists and all the characters in the path should be normalised (e.g. change %20 to spaces).

In addition, careful programming on the web server is very important as are the use of security software, patches and vulnerability scanners.

Conclusion

These are but a few of many security vulnerabilities presented by the PHP web application setup – there are many more. But there are certain fundamental things one can do to prevent the bulk of the worst and most damaging attacks.

To recap:

Firstly, all data that comes from outside your web application must be validated, filtered and sanitised – failure to do this leaves you wide open to attacks.

Secondly, all error outputs should be turned off once the application is live, as they can give attackers vital information about the web application such as database and table names. Once live, all errors can be written to a log file instead.

Controls and directives which allow files to be uploaded to your site should all be turned off unless absolutely necessary. These configurations would be set inside the php.ini file. PHP configuration can directly influence the severity of the effects of an attack and are often set to insecure values by default…the recommended settings for maximum security are:

register_globals – OFF
allow_url_fopen – OFF
magic_quotes_gpc - OFF
safe_mode and open_basedir – enabled and correctly configured.

Variables should always be initialised as uninitialised variables present a huge security risk.

Development accounts (such as username: admin, password: admin) and default usernames and passwords should always be eradicated before the site goes live.

PHP Frameworks and prebuilt CMS applications are generally very secure and could be considered an option for inexperienced developers.

Consider using security applications and testing software to check the security of your applications – there are many PHP tools to test code security such as PHP Security Scanner, Spike PHP Security Audit Tool and PhpSecInfo.

References

Web references:

Breaking down scary terms and what they mean: http://technosailor.com/2010/12/30/infosec-101-breaking-down-scary-terms-and-what-they-mean/
Chapter 11: Shell commands: http://omake.metaprl.org/manual/omake-shell.html
Common PHP Security Mistakes and What You Can Do About Them: http://www.eweek.com/c/a/Security/Common-PHP-Security-Mistakes-and-What-You-Can-Do-About-Them-427112/
Directory Traversal Attacks: http://www.acunetix.com/websitesecurity/directory-traversal.htm
Five common Web application vulnerabilities by Sumit Siddharth, Pratiksha Doshi : http://www.symantec.com/connect/articles/five-common-web-application-vulnerabilities
How to Fix PHP Vulnerabilities (So Your Site Won’t Get Hacked): http://www.codediesel.com/php/how-to-fix-php-vulnerabilities/
HTTP cookie: http://en.wikipedia.org/wiki/HTTP_cookie
Introduction To PHP Security Vulnerabilities: http://debuggable.com/posts/introduction-to-php-security-vulnerabilities:480f4dfe-97f8-4975-ab28-4eb0cbdd56cb
mysql-real-escape-string : http://www.php.net/manual/en/function.mysql-real-escape-string.php
Path Traversal: https://www.owasp.org/index.php/Path_Traversal
PHP dig: http://www.phpdig.net/ref/rn41re781.html
PHP Top 5: https://www.owasp.org/index.php/PHP_Top_5
PHP Security: http://en.wikipedia.org/wiki/PHP#Security
Rfi (remote File Inclusion) What Is It? How Do I Stop It?: http://www.knowledgesutra.com/forums/topic/61805-rfi-remote-file-inclusion-what-is-it-how-do-i-stop-it/
The Cross-Site Scripting (XSS) FAQ: http://www.cgisecurity.com/xss-faq.html
Threat glossary: http://www.h-spot.net/threat_glossary.htm
Top 7 PHP Security Blunders: http://www.sitepoint.com/php-security-blunders/

The importance of Web Accessibility: how to build an accessible website

Neuromedia — Sat, 17 Dec 2011 11:59:39 +0000

1. Introduction

Definition

Accessibility in its broadest sense is the ease with which one can access, read and understand the information on a web page. It is influenced by many factors including disability, the browser being used and the functionality supported by the user’s browser. In order to design an accessible site, the web developer must adhere to standards and practices which will result in a website that is cross-browser compliant, available across all hardware platforms and accessible to those with physical, visual or cognitive disabilities (estimated to be about 1 in 10 people), and by extension, any enhancement software that these individuals might use to access and browse the internet. The most important fact to remember is that the content of the site is what the user is there to read and it should take precedence over presentation where ease of access is concerned.

In short, an accessible website can be browsed and understood by anyone, regardless of visual impairment, physical or cognitive disability, choice of browser, device or personal preferences.

Types of disability and general considerations

Aside from the challenges of coding a website which caters for disabilities, developers need to deal with the simple fact that HTML is a constantly evolving language and that its features are supported variably from one web browser to the next. Thus the first consideration must be cross browser compliance. In order to achieve this, graceful degradation of code is vital. As the browser reads code, it skips anything it cannot understand and reads the next thing. Graceful degradation means that when using new features in HTML, they must always be followed by the older features as an alternative so that anything new not recognised by the browser will be replaced by older features.

Next, the platform on which the internet is accessed must be dealt with and the developer must produce a design which is available across diverse platforms such as mobiles, tablet PC’s, gaming consoles, laptops and home computers.

The technologically limited should also be considered – people with slow connections or low bandwidth will be heavily affected by download speed (e.g. poor infrastructure in third-world countries or people using mobile devices), so the designer should try to ensure the fastest load speed possible.

Finally, accessibility concerns regarding disabilities must be addressed and each type of disability presents its own set of considerations which affect the design process. Listed below are the most common types of disability and some general notes on the challenges faced by users and designers. A more detailed examination of certain aspects follows thereafter.

1. Visual impairment

Colour-blindness: These are individuals who have difficulty seeing colour or distinguishing between colours. Colour-blindness is usually either monochromatic (the user can only see black, white and shades of grey), red-green colour-blindness (the most common, where red and green are indistinguishable) or blue-yellow colour-blindness (where blue and yellow are indistinguishable).

The web developer needs to be very careful about using colour to convey information when considering colour-blindness. Another consideration is the use of colours for text and backgrounds as the wrong combinations may be rendered indistinguishable to a colour-blind person.

Poor eyesight / low vision: These users will often increase the default size of the text on a page or use magnification software (e.g. Zoomtext) to scan the page. Some may use the magnification software in conjunction with a screen reader. It is important to remember when designing, that magnification software only highlights small areas of the screen at a time and that scrolling or moving content will most likely be unreadable because of this.

Blind: The blind generally use screen reading software (such as JAWS or Windows Eyes) to browse web pages. Some (but not many) use a refreshable Braille interface. The screen reader reads content as it appears in the HTML code, and the most important consideration here is that content and presentation are kept separate (by means of stylesheets) and that content is presented in a logical order, with the main content as close to the beginning of the body as possible.

In addition, pages and vital information must never be dependent on images alone and all images on the site must have descriptive ALT tags (unless they are for decoration only, in which case they can be named alt=”” which will be passed over by the screen reader). Important to remember is that users of screen readers use the keyboard only and not a mouse, so the site must be navigable by keyboard.

2. Auditory impairment

All audio material on the website must have a textual representation in the form of a transcript if the site content is to be available to deaf people. Transcripts are also useful to people working in very noisy environments or people without access to speakers. The developer could consider asking for signing to be made available on very important video presentations.

3. Physical impairment

This refers to people who are permanently disabled or temporarily injured and are unable to exert fine motor control and have very limited or no use of a mouse. Depending on the disability, they will use voice navigation software (such as Dragon Naturally Speaking) or devices which approximate the functionality keyboard tabbing. In designing, the absence of fine motor control must be taken into account when deciding on the size of page elements.

4. Cognitive and learning impairment

This refers to people who have difficulties with memory, problem-solving, perception, conceptualisation, reading and comprehension (e.g. dyslexia, learning disabilities). Some of these users make use of ‘browse aloud’ software (e.g. Textic) with which words are spoken aloud as they are highlighted in the text. With these disabilities in mind it is important to use simple, easy language and avoid large blocks of complicated text on web pages (which improves general readability too).

With all these considerations in mind, there are many tools out there to aid in the development of accessible websites which aid in the testing of sites and code to ensure they pass the standards as set out by the W3C.

2. Features

What follows is a more in-depth examination of some features and associated considerations with respect to accessibility.

Tables

The most important thing about tables and accessibility is that they should never be used for layout, and only ever used to display tabular data. Screen readers will read across a table and then down to the next row, which means that site content becomes completely jumbled if tables have been used for layout.

If tables are being used to present tabular data, it must be laid out in a logical order and the use of spaces at the end of cells and breaks at the end of rows is recommended. The use of rowspan and colspan are not recommended and complex tables with multiple levels of headings and well as the use of columns of empty cells should be avoided. Tables can be captioned using the tag to make them easier to identify, or they can be summarised using invisible text or the summary attribute, which is read by the screen reader but does not appear on the page.

The (table header) tag can be used in place of and tags to contain data such as column and row headings. Tables can also be divided into grouped sections using (containing the header elements like labels), (containing the actual data) and (containing column totals, etc) tags. Using the tag allows the body to scroll while the head remains static, which is useful for devices with limited screen space like mobile phones.

Navigation

Navigation as discussed here applies to both the actual navigation bar, and to methods of navigating about a page and between pages.

The most important thing to ensure with the navigation bar of the site is that it remains consistent throughout the site – this is not just general good practice, but also assists those with difficulty seeing or concentrating to always know where they are on a page. The navigation bar should stand out from the rest of the site and be distinctive with respect to colour and contrast so it is not confused with any of the other elements of the page. The links on the bar should be very clearly named and descriptive, they should make it easy to access all the content on the site and they should also be of sufficient size to present a big enough target to those who have limited motor control (meaning sufficient padding around each link and the use of the ‘display: block;’ property).

Also, it is regarded as a good idea to place certain elements at ‘expected’ places on a page (such as the search bar on the top right), which aids those using screen magnifiers (which show only a small portion of the screen at once) to know where to look for them.

For people using screen readers, it is vital to include ‘skip links’, placed before the navigation in the code, allowing the user to choose to omit having the reader software read out the full navigation code and to have the main content as close to the top as possible. These links typically skip to the most commonly used features; ‘skip to main content’ and ‘skip to search’, ‘skip to sitemap’ for example. They can be made invisible by being absolutely positioned off the screen so that the screen readers will read them in the code, but sighted users won’t actually see them. Hidden text can be used anywhere on the site to provide context or information to the blind.

For navigation within a page the accepted practice is to use heading tags (h1 to h6) for heading up sections instead of just larger font sizes, as screen readers can differentiate headings as the starting point of a new segment of the page, allowing the user quick access to areas of interest. The page heading should be h1. Large font sizes and possibly different colours should be used for the headings to aid those with poor eyesight.

For links within a page, it is important to provide descriptive link text as opposed to links which say ‘click here’ (e.g. view our financial records vs. click here for our financial records). All links on a page should have a focus state with a different colour, which assists users in knowing where they are on a page when navigating by keyboard. Important links can also be assigned keyboard shortcuts by using the ‘accesskey’ attribute.

Having a sitemap is an essential for accessibility – it should be easy to find, logically laid out and easy to read.

Images which require the user being able to see them and click on a specific spot (such as an image map) should not be used for navigation without some form of supplementary navigation. Moving targets which require mouseover action to access them should never be used for links or to convey important information.

Form navigation is also an important consideration and the rule of thumb here is that the form instructions and information should always come before the form fields in the HTML, as the blind user will need to know what to do with a field before filling it in. Instructions should also be clear and explicit about the type of content required, allowable content and whether the field is required. Form elements should also always be correctly labelled, which aids not only the blind, but also those with reduced motor control, as the text becomes clickable. Forms must all be tag navigable for keyboard-only users.

Relative font sizes

Poorly sighted users will often either change the size of the default text on a page, or zoom into the page to read the text. Text must therefore be resizable and the page must not break if the user zooms into it. The use of fluid layouts is important here.

Using relative font sizes is simply specifying which text on a page is larger or smaller than other text on the page, all of which is relative to the default text size that the user has chosen. Relatively sized fonts scale smoothly when being zoomed, whereas absolute font sizes can pixellate. Some browsers have issues altering the sizes of absolutely sized fonts.

Relative font size is define using % or em, and fixed font size using point size or pixel values (px or pt). Often, base font size will be defined in the body CSS (in pt) and then all other font sizes are percentages of that.

Frames

Frames are largely obsolete and seldom used anymore and for the purposes of accessibility, they should only ever be used to fulfil a function which cannot be achieved by any other means. Frames present screen readers with huge navigability issues and cause confusion with backward navigation and other functions.

In cases where frames must be used, the content must always be provided in an a alternate