accessibility Archives - Web Accessibility

Five UK Accessibility Testing Companies

Here are five different UK based companies that all offer accessibility testing services. They all can perform a range of accessibility tests to help you improve your web services, making them more accessible to everyone.

AbilityNet

The oldest of the five, at over twenty years, formed in the 1980s and possibly the largest. They are a charity limited by guarantee and have multiple offices across England.

Userite

Part of Website Auditing Ltd, a company formed in 2000, based in London England, with a single focus on web accessibility. Has a network of user testers across a range of ages and abilities.

Test Partners Ltd

Another private limited company founded in 2001, also based in London England, with a focus on software and web testing.

Digital Accessibility Centre

A non-profit organisation and a social enterprise, formed around 2012 offering accessibility testing and employs a team of user testers using a range of different assistive technology.

AccessEquals

This is the newest of the five, only formed in 2015 and is probably the smallest. With a focus on web accessibility offering testing, training and bespoke services.

My journey into web accessibility

A little background about me and my journey into web accessibility.

Who am I?

My name is John Sexton and first started learning about the web in 1999 at a short web media course at a local college. This was my first look at HTML and basic CSS. I progressed to JavaScript and started work as a web developer at Newham NHS in 2001. I had been using screen readers since 1990 with MS Dos and then Windows from 1997. I have a degenerative eye condition called retina dystrophy, which I believe to be a little similar to RP (retina pigmintosis).

During my time at Newham NHS, I developed skills in ASP, VB Script, MS SQL, PHP, MYSQL, XML and jQuery. I developed their Intranet, various web applications for different NHS departments as well as there public facing website. I also got my first guide dog Rebel, a large German Sheppard, in 2005, who quickly became very well liked by everyone.

When I first learned about WCAG

Around the time I was tasked with producing the Newham NHS public facing website, part of the remit was NHS guidelines and web standards. This is when I first learned of WCAG. As I was already a long standing screen reader user, many of the WCAG guidelines I had been already following due to my own access needs. However, I quickly learned through attending various events that there are many more access requirements different to my own and I became an accessibility advocate.

Difficulties as a visually impaired web developer

Having a severe visual impairment has its fair share of difficulties in every day life and its no different in the work place. Many systems companies choose to use will have varying degrees of accessibility issues and often as the employee, you don’t get to say what systems get chosen. So after twelve years of service at the NHS, I was made redundant and started work for a local small web design company. After six months it was time for me to try something new and I decided to go freelance.

What am I doing now?

I am building my network of web accessibility enthusiasts and like minded developers. Sharing my experiences of web accessibility and beta testing WordPress to help with the future of its accessibility. Plus I am working on a community based project for the Native Instruments Traktor DJ community.

What are my interests?

Writing code, latest gadgets and digital DJ mixing and production. As after leaving college in 1991 I started mix DJing and did mobile discos up to 1999.

If you’d like to learn more, just ask in the comments.

Web listening challenge, give it a go

Take a week to browse the web in my world. See how things work when you can only listen to content.

The challenge

Download this open source screen reader software NVDA and install it on your PC
Take a little time to learn the below key strokes
Each day for a week, switch your monitor off and attempt to browse the web, using sites you use every day
Write your experiences, frustrations and things you’ve learned
Share these thoughts either on your own blog, your favourite social media or send us your thoughts

Key strokes

These are commonly used key strokes in NVDA to help move around web page content. They work across popular browsers like Chrome, Firefox and Internet Explorer.

1 = Next level 1 heading
2 = Next level 2 heading
3 = Next level 3 heading
4 = Next level 4 heading
H = Next heading
G = Next graphic or image
T = Next table
L = Next list
K = Next link
E = Next edit box
D = next land mark
Tab = Next link or control

Note pressing shift plus any of the above keys will go to the previous item. IE Shift+1 = previous level 1 heading.

Space = activate link or control
Enter = Submit or activate link or control
Home = Start of line or current item
CTRL+Home = Top of page
End = end of line or current item
CTRL+End = Bottom of page
Cursor Down = next item
Cursor Up = previous item
Cursor Left = previous character
Cursor Right = next character
Alt+D = go to the address bar
Alt+Left Cursor = back a page
Alt+Right Cursor = Next page

There are more controls documented in NVDA’s help although the above will be enough to get started browsing.

Reason for the challenge

I want to help spread the word of web accessibility to more people, this in turn changing the way people think about how they produce websites and their content. The internet can give the best level of accessibility to the widest groups of people no matter the technology people may use. It is the only communication media that can give visual, auditory and touch sensory access.

So if you are up for a challenge and want to make the internet a better place, have a go and share your experiences.

Why infographics are not accessible

In the visual world of social media a popular content called infographics is creating accessibility barriers.

What are infographics?

These infographics are a collection of images, shapes, colours and text placed into a single image, then posted and shared across social media. There purpose is to give a quick snap shot of some content, that can be easily shared, branded and placed within blogs or other content.

Why are they not accessible?

The mixed content placed into a single image has more information than what is suitable for a simple alt text and in most cases do not have full text equivalent content placed adjacent or linked to from the infographic.

This results in people who can not see the infographic image being left in the dark. Often these images have no alt text at all. Plus because the text content is placed inside the image, people can not scale the text up or change colour or font.

What can we do to change this?

I believe the way forward is to make better use of SVG (Scalable Vector Graphics). This will both allow for clear scaling and assistive technologies can programmatically access text and other components of the image.

There is already research being done on how to make charts and diagrams more accessible through SVG2.0 and I believe the same can be done for infographics.

Conclusion

Remember that visual only content is no value to those who can not see it. The same as audio only content has no value to those who can not hear it. Text alternatives are the first guideline of WCAG2.0 Level A and not providing suitable text alternatives for infographics will break this guideline.

We are not saying to never use images or infographics it’s quite the oposit. Instead we are saying that there are always sufficient alternative text content made available to ensure they are accessible to everyone.

WCAG2.0 Level A automated checks unveiled

There are many software products that claim to check WCAG2.0 guidelines. Here we talk about which checks can be managed with software and what will need manual checks made by people. For more details about what these checks are for take a look at the previous article WCAG2.0 Level A, your guide part 1.

Perceivable

1.1.1 Non-text Content: It is possible to have software check for things like, does images within the HTML content have alt attribute and check if the value is not empty. It may even check for common mistakes like alt text that starts with "image of" or "photo of" or "picture of". It may even check for the presents of words or single character alt text like "*" or "-". However, it can’t check if the alt text relates to the image purpose or that the inline placement of the image makes sense and doesn’t cause any confusion. These checks require people to make a judgement.

1.2.1 Audio-only and Video-only (Pre-recorded): It may be possible to check if a video has an audio track, However, it isn’t possible to check for relevance or that the same information is presented in an alternative format. This will need people to check manually and may require some isolated testing of each format for comparison.

1.2.2 Captions (Pre-recorded): Again it may be possible to check if captions exist but not ensure that the captions are relevant, complete and usable. It will take people to manually check captions against the media content to ensure it’s a suitable alternative.

1.2.3 Audio Description or Media Alternative (Pre-recorded): In some cases, it may be possible to check if a separate audio description track is present but it will need people to ensure that the audio descriptions are accurate, provided clearly and in a usable timely way.

1.3.1 Info and Relationships: It is possible to check if specific HTML tags are used and if all HTML headings follow hierarchical structures. Although it can not check if the content is making best use of HTML semantics or if the text used makes sense and is relevant.

1.3.2 Meaningful Sequence: It is possible to check for the use of the tabindex attribute but it will take manual checks to see if the ordering is logical and makes sense.

1.3.3 Sensory Characteristics: It may be possible to check for commonly used phrases that may break this guideline but it will need manual checks by people to see if the guideline is actually broken or if the text instructions will make sense to all people.

1.4.1 Use of Colour: It may be possible to check the colours used or for any common colour names used in text. However, it will take people manually checking to see if colour is being used solely for identifying content.

1.4.2 Audio Control: It may be possible to check if a page has any audio start automatically and if that audio lasts longer than two seconds. However, it will take manual checks to see if the controls are accessible for everyone and any assistive technology.

Operable

2.1.1 Keyboard: It may be possible to check that if mouse events are used that keyboard or focus events are also used. However, it is not possible to automatically check that all controls can be used via a keyboard. Or that any mouse controls can equally be controlled by a keyboard without any loss of functionality or information.

2.1.2 No Keyboard Trap: It is possible to check for potential cases of keyboard traps but not check for the effects or if it will cause people any difficulties. This will take manual testing by people.

2.2.1 Timing Adjustable: It may be possible to check if any timing events are being used but it will take manual checks to measure the effects and decide if any exceptions can be made.

2.2.2 Pause, Stop, Hide: It may be possible to identify some instances of blinking or animation but it will take manual checks by people to see if they break this guideline or if any exceptions can be made.

2.3.1 Three Flashes or Below Threshold: It may be possible to check for the existence of potential high risk content but ultimately it will take people to make a judgement on how to approach the content and to manually check all media and dynamic content.

2.4.1 Bypass Blocks: It is possible to check if any internal page links exist but it takes manual checks to see if these links work effectively and serve a useful purpose.

2.4.2 Page Titled: It is possible to check if page titles exist and are not empty. However, it takes manual checks by people to ensure the titles are relevant and make sense.

2.4.3 Focus Order: This can not be automatically checked, it takes manual checks by people to see if the focus order is logical and makes sense.

2.4.4 Link Purpose (In Context): It is possible to check that links contain text, even check that duplicate link text doesn’t point to different locations. However, it takes manual checks by people to ensure that the link text used, is relevant and makes sense both in and out of context.

Understandable

3.1.1 Language of Page: It is possible to check that a page language has been specified. However, it will take people to ensure that the language set is indeed the default language for the page.

3.2.1 On Focus: It is possible to check for potential issues by finding any on focus events but it will take manual checks by people to measure the effect and see if it breaks this guideline.

3.2.2 On Input: Again it is possible to highlight potential problems but it will take manual checks by people to ensure that adequate notification is given and no unexpected action will result in confusion.

3.3.1 Error Identification: This will need manual checks by people to ensure that any errors are shown in text and that the it makes sense and is clearly indicating where the error is.

3.3.2 Labels or Instructions: It is possible to highlight missing form labels although it takes people to ensure that the instructions are suitable, clear and that all labels make sense.

Robust

4.1.1 Parsing: This can for the most part be checked by automated software, the W3C Mark-up Validation Service, is one example. However, it take people to ensure that the content is marked up with the best use of semantics.

4.1.2 Name, Role, Value: It may be possible to check for the existence of these attributes and values not being empty. However, it will take manual checks to see if the values make sense, are relevant and provide useful assistance with navigation or operation.

Conclusion

Even at this lowest level of accessibility, the kind of things that can be checked effectively with automated software is very limited. Plus if many of these checks are made during template design and content creation, it can save both time and money with checking and then having to re-engineer or change content after it’s already been published.

Remember for each level up with WCAG2.0 guidelines, you first must meet all of the previous WCAG2.0 level. So to be WCAG2.0 Level AA, you first must meet all WCAG2.0 Level A and then all WCAG2.0 Level AA checks.

Share the love

If you found this article useful, please share and send it to a friend

WCAG2.0 Level A, your guide part 1

Here we will look at the WCAG2.0 Guidelines level A. This is the most basic level of accessibility and without it, will prevent many people from being able to use your website. It may also impact the level of usability for everyone not just people who may have an impairment.

The guidelines are based on four principles POUR, see the article Get started with WCAG2.0 for an overview.

Perceivable

1.1 Text Alternatives

1.1.1 Non-text Content: Any of your web pages content that is not in regular text, such as images, video, sound, Flash or other similar content that is available to your visitors, must have a text alternative that gives an equivalent purpose, except in the cases listed below.

Regular text is any text that can be selected and understood by other technologies, such as text editors. It does not include text that is embedded into images, videos or spoken within audio. A simple test is to see if you can highlight the text and copy it into a text editor like notepad.

For web controls such as buttons or forms you give them text names or text labels that will explain their purpose, see WCAG2.0 4.1 for more details.
For time based media, the text alternative should at least give a description of the media, see WCAG2.0 1.2 for more details.
When providing a test or exercise in a text format would be invalidated you should at least give a description of the non text content.
When the primary purpose is for creating a specific sensory experience, you should at least give a description of the content.
When using CAPTCHAs, you should at least give a description that identifies and explains the purpose of the CAPTCHA. You should also provide alternative CAPTCHAs for different types of sensory perception. These may include, visual, audible or touch, see the article Captcha should it stay or should it go.
For cases when using visual effect for pure decoration or only for visual formatting, or is not to be shown to people, you should use a method that is not visible to assistive technology. Things like placing decorational images as CSS backgrounds instead of HTML image content.

1.2 Time-based Media

these guidelines do not apply when the audio or video is used as an alternative for text content and is clearly labelled as such. There is more information at WCAG2.0 Understanding Guideline 1.2.

It is worth noting that these guidelines address people with either hearing or visual impairment but do not address accessibility issues for people with both hearing and visual impairments or may not address people with cognitive impairments. Remember any time based media may effect people’s access especially for those who take more time to access and understand the content.

1.2.1 Audio-only and Video-only (Pre-recorded): An alternative for time-based media is available that gives the same information for pre-recorded audio-only content and Either an alternative for time-based media or an audio track is available that gives the same information for pre-recorded video-only content.

1.2.2 Captions (Pre-recorded): Captions are available for all pre-recorded audio content in synchronized media,.

1.2.3 Audio Description or Media Alternative (Pre-recorded): An alternative for time-based media or audio description of the pre-recorded video content is available for synchronized media.

1.3 Adaptable

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. This refers to things like HTML semantics, for an example see the article Get started with Structured Headings.

1.3.2 Meaningful Sequence: When the order in which content is given affects its meaning, a correct reading sequence can be programmatically determined. This refers to things like the tab ordering and the HTML order of content as appose to any visual layout being used. It is there to help ensure assistive technology can follow the order of information as it is intended without out loosing any meaning.

1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. This is to allow people to follow instructions regardless of which Sensory control they are using such as audio, visual or touch.

1.4 Distinguishable

1.4.1 Use of Colour: Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Operable

2.1 Keyboard Accessible

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. For example if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not. You are not advised to avoid other input methods like mouse or touch screens but instead allow for both. See the article A Little Accessibility Guide to Device Independence.

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, like the escape key, the user is advised of the method for moving focus away. Common examples of keyboard traps are embedded objects like Flash or JavaScript that takes control over the keyboard input.

2.2 Enough Time

2.2.1 Timing Adjustable: This helps ensure that people can complete tasks without unexpected changes in content or context that are a result of a time limit. You should not use time limits on content unless one of the following applies:

People are able to turn off the time limit before it starts.
People are able to adjust the time limit over a wide range that is at least ten times the length of the default setting and before it starts.
People are warned before the time limit expires and are given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and they are able to extend the time limit at least ten times.
The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible.
The time limit is essential and extending it would invalidate the activity.
The time limit is longer than 20 hours.

2.2.2 Pause, Stop, Hide: For any moving, blinking or scrolling information that starts automatically, or lasts more than five seconds, and is not the only content available, there needs to be a way for people to pause, stop, or hide it unless it’s part of an activity where it is essential. For any auto-updating information that starts automatically and is not the only content available, there needs to be a way for people to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

Content that is updated periodically by software or that is streamed to the browser is not required to keep or give information that is generated or received between the pause and resume action as this may not be technically possible, and in many cases could be misleading to do so.

An animation that occurs as part of a preload phase or similar case can be treated as essential if interaction cannot occur during that phase for all people and if not indicating progress could confuse people or cause them to think that content was frozen or broken.

2.3 Seizures

2.3.1 Three Flashes or Below Threshold: Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. This is to prevent people susceptible to photo-sensory related Seizures from having attacks provoked by your content. This will include animations, video or interactive content.

If you have any content that may not comply with this guideline, it is important that you make people aware before the content is shown and allow people to choose weather to proceed with the content.

2.4 Navigable

2.4.1 Bypass Blocks: Give people a way to bypass blocks of content that are repeated on multiple Web pages. This refers to things like skip links and is there to help people get to content more easily.

2.4.2 Page Titled: Web pages have titles that describe topic or purpose. This is both a SEO (Search Engine Optimisation) and accessibility requirement. The more relevant and concise the title the better. It should reflect the topic and purpose of the page and not the website in general.

2.4.3 Focus Order: This refers to the order in which items that can have focus like links, form fields, buttons and any control that people can interact with are placed. It is important that this order makes sense to people regardless of the device or assistive technology they may be using.

2.4.4 Link Purpose (In Context): The purpose of each link can make sense from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be confusing to people in general.

Understandable

3.1 Readable

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. This refers to adding a base language to the page that can be used by assistive technology and web browsers.

3.2 Predictable

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. This is to prevent any unexpected behaviour when people are moving focus from one place to another, This includes tabbing or clicking into a text field. You can read more on WCAG2.0 Understanding on focus.

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component. This is about always informing people of any unpredictable changes, things like a link opens in a new window. As this is not the default action of a link and may cause confusion. For more information see WCAG2.0 Understanding on input.

3.3 Input Assistance

3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. When identifying errors with information entered by people, it is important to do this with text and not through images, colours or sound alone. This is to ensure it is available to everyone regardless of technology used.

3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. This is for things like web forms, search boxes or login screens. Anywhere people need to enter information, suitable instructions and labels should be given.

Robust

4.1 Compatible

This is about following code standards and best coding practices to ensure the code will work equally well across multiple browsers and with various assistive technologies. You can see more about device independence and assistive technologies in the article A Little Accessibility Guide to Device Independence.

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

This is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this guideline when used according to specification.

Conclusion

For WCAG2.0 Level A, the first and lowest level of accessibility guidelines, it has 25 different things to check. These are across all four POUR Principles and broken into guideline categories like 1.1 Text Alternatives.

You can appreciate after reading through these initial guidelines, that knowing a little about assistive technology and how people use these technologies, why the guidelines exist.

My next post will go over each of these 25 checks and explain why I believe they may or may not be tested with automated systems.

Don’t miss another accessibility article!

Enter your email below and get free updates as soon as they become available.

We respect your privacy and do not spam.

Accessibility with Braille display technology

Ever seen one of these? It’s an internet ready refreshable Braille note taker. Yes, a web browser in a portable Braille display.

Is your website truly cross platform?

You may of worked hard to ensure your site works across different screen sizes, from mobiles to large HD displays. Tested it works in all the latest browsers from Safari, Chrome, Firefox, Opera and Internet Explorer. This is all great but what about Braille devices?

What are and who uses Braille displays?

A Braille display or note taker like the U2Mini, are an electronic device that uses a matrix of pins that pop up in different patterns to create the tactile writing called Braille. Invented over two hundred years ago by Louis Braille in France. This is generally associated with the blind but is a life line to people with both sight and hearing loss. Devices like the U2Mini can be used independently and often have WIFI, Bluetooth connectivity with internet browsing built-in.

These devices generally don’t have any mouse pointer so interact with websites in much the same way as screen reader software does, via the keyboard. The other key point, is the display is only made up of a limited number of Braille characters all on a single line. The user will need to scroll through the information, only being able to read one small section at a time. A little like screen magnification software. Plus there are no indications of colour in Braille, so any reference to colours can not be used in Braille.

You may notice, the keyboard is not a conventional querty keyboard but instead a Braille keyboard. The device will manage the interfacing between the Braille keys and the expected ASCII keyboard input on your website. So you don’t need to know how to read or write Braille to support these devices.

How can we test for Braille devices

Don’t worry, you won’t need to rush out to buy one of these, for most it would be a very costly waste of time, especially if you don’t read and write in Braille.

However, there are things you can do, like follow best practice for device independence and progressive enhancement, don’t rely on colour alone to identify something and ensure you have suitable alternative text for non text items. Many of the WCAG2.0 POUR principles will still apply, so understanding these can only help you produce accessible web content.

If you want to go the extra mile you can always ask people who use Braille displays to give feedback on their experiences. There are many user groups and specialist accessibility auditors who use teams of people to perform user testing with all kinds of devices.

Have your say

Ever wonder how people with sight and hearing loss can get equality through the internet?
Ever wonder how blind people can communicate with deaf people?
Ever seen a Braille display in use?

Think Accessibility, make a difference with our Free offer today!

You can make a difference to over a fifth of the community just by taking the first steps in web accessibility and for Free! Keep reading to find out how to make the most of our Free offer.

What can I do?

The very first step, is reading this and having a browse over my blog. It’s free, so accessibility need not break the bank.

The next step and a very important step, is to act now and take advantage of my Free offer.

What is the Free offer?

The free offer is a basic accessibility check of one page of your website. This check will look at common accessibility issues and highlight these together with why they effect people and give suggestions on how to address them. The tests are subject to availability and are offered without warranty.

What are the catches?

There are no catches, the tests will be carried out by myself, using my specialised skills and experience in web development and accessibility. You will get a short report highlighting any issues found with reasons, people who it effects and guidance on resolving them.

However, if you find the report useful, if it helps you improve your level and understanding of accessibility and want to provide a testimonial of your experience to share on this blog, I’d be happy to share the love.

What are the requirements?

You must be the owner or responsible for the web page to be tested.
You will need to insert a short HTML comment into the page before I can perform the test. This just helps ensure you are indeed the web page owner or that you are responsible for it.
Your web page must be on the public domain, available on the world wide web. Sorry, I am not able to offer this to private intranet or extranet web pages.
You will need to complete the below form. Please ensure you enter your email address correctly.

Get your free offer now

Testimonials

Sarah Arrow

John’s insights on usability are simply brilliant. His advice enabled me to adjust various settings on my site to make it easier for the visually impaired. His demonstration of how his sight reading device spotted an error that hundreds of other people missed! Connect with John, you’ll love what you learn.

Accessibility Testing, the how, what and why

It is still a bit of a minefield when it comes to accessibility testing, how do we ensure good value and that we are getting the right advice and support?

Types of accessibility testing

This generally falls into three categories, automated tests, manual tests and user tests.

Automated accessibility tests

These are computer based tests that can scan your web pages a little like the way search engines scan pages. These start from free online tests to corporate software systems costing thousands a year. They can not do a full WCAG2.0 test at a level that will ensure an accessible and usable experience for everyone. They can have a benefit over manual tests in that they are faster and less susceptible to human error. However, automated systems can be tricked and depending on the level and complexity of the test, may give false results.

Manual accessibility testing

These require a methodical approach and a high level of technical knowledge from the tester and can take considerable time for large and complex websites. They do have the advantage over automated testing in that it is harder to full a human test compared to computer tests. They are most cost effective when used on new website designs or for new features of existing sites. As it can reduce the need for re-working or re-building entire sections of code and infostructure. However, it is susceptible to human error and may include individual opinions.

User accessibility testing

This type of testing can give you the most valuable information regarding user experience but will depend on the way testing is managed and monitored. For best results it will need to take into account the nature of your website service, the target audience and a number of people testing with different assistive technology.

How often should accessibility testing be done

This will depend on factors like: how often is your site content updated, how many people manage content, the type of content used and what process you have in place for supporting your website visitors. It will also rely on the accessibility awareness of the people producing your web content.

It should be checked at least once a year for relatively static sites and at least quarterly for more frequent updates. For sites with daily updates and frequent new feature updates, it should be incorporated into your project flow as part of the QA (quality assurance) process.

What value is there in accessibility testing conformance badges

Personally I feel there is little to no value a part from showing what accessibility testing service you use and perhaps to indicate that you may have an accessibility budget. They only verify that you had a specific accessibility testing process carried out by a particular provider at a given time. It does not prove anything, as you may of broke accessibility guidelines the day after having the badge awarded.

However, if it is a recognised or required badge within your specific organisation, then it may have some credence. The W3C WCAG badges are self awarded and again give no proof of accessibility testing ever been done.

Can I do accessibility testing myself

Yes, although the level of accessibility and quality of testing results will greatly depend on your personal knowledge and experience across all areas of accessibility. This will be particularly limited in the area of assistive technology as this is a vast specialist area and very difficult to emulate different accessibility requirements.

However, there are a few things you can do to help you gain some empathy with a few areas of accessibility. Things like unplug your mouse and just use the keyboard, install a screen reader like NVDA and take a little time to learn the controls before unplugging or switching off your monitor and just working with the screen reader, you can also unplug or switch off your speakers. The kind of things are very difficult to emulate include dyslexia, Braille displays, voice activation, specialist keyboard/pointer devices and cognitive related issues.

Conclusion

Accessibility testing is a specialist part of UCD (User Centric Design) that forms the bases for any good UX (User Experience) or UI (User Interface). It is about striking a balance between many different situations and people to give the best possible experience for everyone and should be a part of your web management process. It is not a one off process that you can just tick a box and forget, it is a on going journey just like marketing or customer relations.

Alt Text, your quick guide

Alt text is short for alternative text and is a requirement of WCAG2.0 level A, for all web image content. The most basic level of accessibility and probably one of the most missunderstood issues.

Alt text, the what and why

In HTML, you can include images to be displayed in your web pages. This is done through the tag <img>. If you are using a CMS or other web content editor, you may only know it as uploading an image. Inside this <img> tag, you can add an alt text value. It doesn’t do anything visually in most browsers except older versions of Internet Explorer, which shows this alt text value when you hover the mouse over the image.

The single purpose of this alt text is to provide a short text alternative to the image for cases when the image can not be seen. This may be for a number of reasons from the browser doesn’t support images, the image failed to load or the person viewing it is not able to see due to sight impairment.

What text do we use

The first thing to note, is the purpose of the image. If the image is used as a link to something and there is no link text being used, then the purpose is to link to something.

So for instants, if we have an image of a satellite dish that is used to link to Sky TV, the alt text should say "Sky TV" and not "Satellite Dish". This is because the text Satellite Dish, does not tell you anything about the purpose of the image where as Sky TV tells you what to expect if you follow this link.

Embedded text, this is text saved inside the image that can not be selected or copied into a text editor. If your image contains embedded text then this should be included in the alt text. Unless the text in the image is too long or not relevant. So if you have a button image with the text "sign in" inside it, then your alt text should say "sign in" and not "login" or "button". This can avoid confusion when people refer to what they see when talking with people who are not able to see the image and rely on the alt text.

Generally you should avoid using embedded text, where possible and especially for long pieces of text. As it does not scale as well as regular text and alt text is only for short alternative descriptions.

Photos and other images that are used to give some general impression but does not add substantial content. These may include a picturesque photo of a location, groups of people or other atmospheric picture. They do not need every detail documented in the alt text. You can simply use a very brief text like "a picturesque view of …" or "friends gathered at …" etc.

Charts, diagrams and other complex data related images, are probably the most difficult as the alt text only needs to be a general comment to say what the chart or diagram is for, say "pie chart showing …" or "flow chart of …" etc. However, as it will also contain substantial content within the image, you should either place this information adjacent to the image in a text form or have a link to a text alternative that says something like "details of the pie chart on …" or "detailed description of the flow chart on …".

HTML does support something known as longdesc, short for long description. However, it is often used incorrectly and not well supported or understood. So either of the other methods are generally preferred. To find out more about using HTML longdesc, see www.w3.org/TR/WCAG20-TECHS/H45.html.

There was some controversy over longdesc in HTML5, you can read a little about this on Bruce Lawson’s longdesc in HTML5 article.

Decorational images, these are images that add no content value to the page and are only there for visual decoration. These may include things like background textures, ribbons, floral borders etc. The best practice is to separate these into your style sheet and not include them within your HTML content. Many people have tried different methods from using null or empty alt text to generic non descriptive alt text like an asterisk “*” or words like “spacer”.

The problem is if you place decorational images inside your HTML, it is treated as content and not just styling. So people who use assistive technology like a screen reader, may be able to detect the image but either get no text or text with no meaning. This can cause people to believe they are missing out on content or just have a distraction to other content.

Tips for alt text

Don’t start with things like "image of …" or "Picture of …" or "Link to …" as assistive technology will already be able to indicate this and it results in people being told twice it is an image before they find out its real purpose.
Keep the alt text short, meaningful and relevant to its purpose.
Place text alternatives for complex charts, diagrams or other data content adjacent to the image or in a separate page linked to from either the image or adjacent text link.
Think carefully before choosing to use the HTML longdesc and remember it is to link to the long description and not contain the long description itself.
Place decorational images in your style sheets, to keep your content and styles separate.
Take care where you place images within your content, inline images placed in the middle of content can be both distracting and confusing, regardless of how it is displayed through your style sheet.
Ask people who use assistive technology, if the content including images makes sense or ask an accessibility specialist.

Conclusion

Understanding alt text is part of the first principle of WCAG2.0 Perception, How people view your content regardless of ability or any assistive technology used. It is in the lowest minimum level WCAG2.0 A and can effect many people as well as your SEO (Search Engine Optimisation).

So taking a little time to understand alt text and just spending a few extra minutes on your page content can make a difference to your SEO and the people who view your web pages.