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.

Captcha should it stay or should it go

CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart), are a system to try and check that it is a person operating the web page and not a computer script. See the official CAPTCHA page for more information.

CAPTCHA’s and Accessibility

These have been a continual problem for accessibility. One of the most common reasons is because the popular image CAPTCHA makes the assumption that the person is able to see the image. The Section 508 US guidelines say that an audio CAPTCHA must be used with image CAPTCHA’s to help people unable to see.

However, this does not address those people who may have both sight and hearing loss or those people with reading difficulties such as different language or dyslexia. There are different styles of CAPTCHA from image, audio, question or challenge based. Each giving a barrier to different groups of people.

Are CAPTCHA’s effective

You may use CAPTCHA’s for many reasons from reducing spam, reducing password hacks to validating polls. However, it is not a full proof solution and adds both an accessibility barrier plus an additional layer of friction to user experience.

The term friction is the amount of things someone will need to do to complete a single task. So by adding a CAPTCHA, it adds to the number of things someone has to do to complete a form, signing or vote etc. Often CAPTCHA’s are difficult to get right, so may take a person several attempts. See this article Do CAPTCHA’s block spam or your readers.

This has made people turn away when coming across a CAPTCHA, which if you are in business, may lose you custom. Read this article CAPTCHA’s vs. Spam bots for some more different types of CAPTCHA’s.

Remember that CAPTCHA’s that depend on anything other than HTML client-side will not work for all cases. As the fact it depends on something that may not be supported in the browser viewing it gives it a floor. For example CAPTCHA’s that use JavaScript depend on the persons browser having JavaScript enabled.

My conclusion

I believe it is simply not possible to have a computer script check with 100% accuracy that it is a person using a web page control while maintaining a high level of accessibility. Plus the additional level of friction may have a negative effect by putting people off using your web page.

However, there are a few basic things you can do like using server-side spam filters or form validation. You could also use time measurements between the first page request and the subsequent associated post request. If this time is only a fraction of a second or no more than a couple of seconds, chances it will be a bot and not a person. Both these methods add no friction to the user experience and are transparent by working in the background.

Another idea is to use a selection of radio buttons and have the default selection to be something like “I am a bot, choose another option if you are human”. This does add a small amount of friction but doesn’t impact accessibility as long as the form is correctly marked up and the label text is easy to follow.

The truth is you can’t have 100% security you can only make a judgement on how much security you need and how much risk is taken. If your resources allow for it, you could have people manually checking all submissions but for most cases, this level is either un-manageable or just not required.

Have your say

Do you use CAPTCHA’s or do you despise CAPTCHA’s?

All views, thoughts and comments welcome.

Get started with WCAG2.0

WCAG (Web Consortium Accessibility Guidelines), were first published in late 2008. These are a revised set of guidelines from the original WCAG published guidelines and aim to address the issue of the rapid changes in technology by focusing on people instead of technology.

Were to start with WCAG2.0

The first thing to note is that they are guidelines not standards. So they are designed to help guide you and are not there to restrict you or be treated as tick boxes.

Where as W3C code standards are exactly that, standards, which should be followed to ensure future compatibility with web browsers. Failing to comply with W3C code standards is likely to result in incompatibility issues across old and new browsers a like.

Although within the UK public sector, it is a requirement that all web services meet the WCAG2.0 level AA guidelines as a minimum standard. This is a good level to aim for and is achievable, However, it may not address all accessibility issues that people may face.

Principles used in WCAG2.0

The WCAG2.0 guidelines use four principles, known as POUR (Perceivable, Operable, Understandable and Robust). Lets take a look at each of these in turn.

WCAG2.0 Perceivable principle

This principle is to ensure that people of all abilities can recognise and take in all the information given on your web page. Plus be able to make out the various sections and controls that they can use. So this will include the way you structure your content, the kind of controls you use as well as the colour and design.

WCAG2.0 operable principle

This principle is about how people use and interact with your website. People must be able to operate all controls on your web page, regardless of what device or assistive technology they may use. So this will include areas of device independence and an appreciation of assistive technology and the different ways people may interact with your website.

In today’s vast range of web enabled devices, it will include everything from touch screens, voice control, Braille or other specialised keyboard as well as your regular keyboard and mouse.

CAG2.0 Understandable principle

This principle is about making sure that your information and the way to use your website is easy and not beyond anyone’s ability. The article Accessibility, it’s in a KIS can help you with this principle.

WCAG2.0 Robust principle

This last principle is about future proofing by ensuring your website code conforms to coding standards and that it can work with assistive technologies. This will include things like cross browser support, mobile responsiveness and again device independence. It will also include code maintenance and removal of deprecated code as well as progressive enhancement or graceful degradation.

Useful resources

Your how to guide for Multimedia and Accessibility

Today’s internet is rich with all kinds of multimedia from image galleries to audio and video streaming to real-time dynamic interactive content.

Where to start with multimedia and accessibility

The first step is to determine what exactly is it you want to achieve. What I mean by this is the message or communication interaction you want to convey between yourself and your visitors.

Say for example, if you are giving a video tutorial on a product, think about the information within that video. Not just what may be spoken but any visual information. It is this that can create your full video transcript.

Then think about your audience, all the different assistive technologies and how people will interact with your web content. From this you can decide about using audio description or signing or captioning within your video.

Lastly before you start work on creating any of these things, think about, progressive enhancement, what will work everywhere?

Next steps in multimedia and accessibility

Using this video example, the one thing that will work with all assistive technology and all browsers, from the things outlined above is your full video transcript. This is because transcripts are typically text based and if any images are included, they should have text alternatives.

So following the progressive enhanced design principles your full transcript will be the default content. Then you can test for video support and if used, support for captioning or other features added to your video. If your video is supported by the visitors browser of choice, you can then show the video and replace the default transcript content with a link to the transcript. This way keeping the choice of a transcript for your visitor, if that is their preferred format.

What about other media content?

Audio will work much the same as video by having a full text transcript. Flash, silverlight or similar content will generally have their own set of accessibility guidelines but again, having a text based version of the information, will allow for cases where the support is not available.

Document links should indicate within the link text what the document format is and optionally its size. It is not required for you to make the same document available in multiple formats to suit individuals personal preference. However, whichever format you choose to use, you should follow any published accessibility guidelines for it.

Charts, diagrams and other visual illustrations are one that can give people with a visual impairment, accessibility problems. This can generally be addressed through text based descriptions and tabular data that relates to the charts. This is one area that work is currently being done in, to try and make use of a mix of sound, tactile and text to speech to help enhance accessibility.

How about real-time dynamic content?

This is typically done with Javascript, so the first step will be to create some kind of basic text alternative. Before checking that the browser being used has support for your content. Then you can apply basic accessibility principles to how your real-time dynamic content is created and interactive with. Things like device independence.

For modern browsers, you can use HTML5 and ARIA. This allows you to specify additional information that assistive technology can use helping to make the content more accessible. Again, giving the user the option to choose the default basic content, will empower them with the freedom of choice.

Wrapping it all up

Rich multimedia content does add to the accessibility requirements but given some thought prior to adding your multimedia, it can still be kept accessible to everyone.

Understanding how people use assistive technology and how they interact with websites plus following key principles of accessibility, it can really help you make a difference.

Accessibility, it’s in a KIS

"It’s in a KIS?" you ask and I say "yes". KIS (Keep It Simple), is a phrase often over looked in today’s world of high tech web2.0 with social media, streaming and new frameworks that seem to be coming out every day!

How can we follow the principle of KIS?

In today’s high tech and rapid development of rich multi-media websites, the first basic principle is forgotten. This is all web pages are built on HTML. Everything else is added on.

Ideally you want to aim to achieve that all your web content and basic functionality will work in plain HTML. This does not include any styling or dynamic activity but should be enough to convey your message and allow some basic functionality like navigation and communication via forms.

Progressive enhanced design

Progressive enhancement is where you check for support of a feature before using it. For example a Flash video, you may place a static image and transcript of the video inside your HTML then check if the browser will support Flash. If it does, you can then replace the static image and transcript with the Flash video and a link to the transcript. This way you are offering the most basic type of content first and only if the technology used allows for it, you show the enhanced content but also still offering the basic content for people who may find it easier.

Many developers when using progressive enhanced design, forget to give people the option of choosing the less enhanced content. So taking the previous example of a Flash video, without adding the link to the transcript, you may be preventing people from accessing your content just because their browser supports Flash. The point is to use progressive enhancement to empower people with a choice and not leave that choice up to their browsers capabilities.

In some cases where the enhancement does not effect actual content, say a print page button, leaving the choice of enhancement up to the browser capabilities is fine. As weather the print function is supported or not, the same message is given, just in a slightly different way. Without support the message may say "print this page for your reference" and if the print function is supported it may show a print button saying "print now for your reference".

KIS and navigation

Your navigation is how people find things they are interested in on your site. If it is different on every page or is very complicated to follow, people will get confused and probably go else where.

There was a myth about a three click rule, that implied you must be able to get all content on your site in no more than three clicks. This generated a flux of mouse controlled multi-level navigation menus with hundreds of links on every page. This style of navigation cause many people great difficulties with using them and getting around web pages. There have been some improvements to this kind of navigation in recent times but I still say "do you really need them?"

Remember, you can place links in many places not just a single complicated multi-layered navigation system. You can use a site map page, keyword search box, aside sections and links within your content, footer or where ever it is most appropriate. The key thing is to make sure they are relevant.

KIS and your content

The web is still an evolving communication media with a fast growth and rapid rate of change. People are still adjusting from the changes from printed media and the web. Social media sites are also impacting our perception of how we use the internet.

Although you can still learn from print publishers way of writing content, using short concise headings, short introductory paragraphs and good use of plain language. There are a few tools designed to try and measure the level of ease of reading such as Flesch reading test and Gunning Fog index.

One thing to ask yourself when writing content, is it what your audience want and will enjoy? Remember people may be viewing your web page on any number of devices in all kinds of places, so bare this in mind.

So to summarise KIS

  • Always try to ensure your key content and basic functionality can work with just HTML. This ensures a strong foundation in which to build upon.
  • When introducing enhancements check they are supported and if it impacts content, give people the freedom of choice. This ensures things don’t brake on older tech and empowers people with a choice that best suits them.
  • Keep your navigation simple and relevant. Place links in the most appropriate section of your page and avoid over loading the page with hundreds of links. People enjoy an easy life, so help by making it easy for them.
  • Ensure your content is easy to read, concise and gives a structure of headings and short introductions to help people quickly find their points of interest.

Have your say

Share with us your experiences, good and bad. Tell us about sites you find a joy to use and ones that are not.

Have any questions, just ask in the comments or use our contact form.

The best of web accessibility in week one

Lest take a look back over the first week here at abc4accessibility.

Day 1 Accessibility and Usability: The first steps

We look at the two terms accessibility and usability and take the first steps into the world of web accessibility.

Day 2 The Smart Design: Accessibility and Colour

Here we take a look at how using colour can effect people and see some of the WCAG2.0 guidelines around contrast in web accessibility.

Day 3 Get started with Structured Headings

On day three we get a look at how to structure our web pages by using headings and why it can effect accessibility for many people.

Day 4 A Little Accessibility Guide to Device Independence

Now we learn a little about what device independence means and the difference to accessibility it makes for people who use the web.

Day 5 Assistive Technology: Introducing the Screen reader

On day five we start to look into the world of assistive technology and introduce the screen reader. We find out a little about who it’s for, how it works and how it benefits people with web accessibility.

Day 6 Your Guide to Accessibility and Screen Magnifier Software

Here we delve deeper into assistive technology and web accessibility by taking a look at screen magnifiers. Again we see how they work and who can benefit by using them.

Day 7 Accessibility for Voice Activation Software

Lastly on day seven we go further into assistive technology by looking at voice activation. We see what it does and how it can help the accessibility for people with using the web.

Bonus 10 Top Tips on Web Accessibility Best Practice

This last post will help you get started into the world of web accessibility. Learning about some of the most common things to be aware of and how to improve web accessibility for many people.

Share the love

If you found these articles helpful, why not share the love and share them with your friends. Please use the share links and help spread the message of web accessibility helping people use the web.

10 Top Tips on Web Accessibility Best Practice

These web accessibility top tips for best practice are based on both WCAG2.0 guidelines and my own experience of web accessibility and assistive technology. It is ment as a starting point and aims to help you make a start on the path to using better web accessibility practices.

1 Use well structured semantic mark up

By following W3C code standards and marking your content with the right HTML tags, you help both future proof and maintain your code and allow assistive technology to work more effectively.

You can read the article Get started with Structured Headings to see the value of using headings within your WebPages.

2 Use colour effectively

Colour is often considered part of the cosmetic design and not have any value to the content. Although for some people colour can aid there ability to read or find content.

You can read the article The Smart Design: Accessibility and Colour to find out more on how to use colour effectively.

3 Ensure device independence

This is key for many assistive technology as well as the fast growing mobile web access. More people are using mobile devices to access WebPages on the go or while relaxing at home.

You can read the article A Little Accessibility Guide to Device Independence to learn the fundamentals of this.

4 Use link text that is meaningful

Link text is the clickable text that will take you to something else. If an image is used instead of text, its alt text will be used as the link text.

Many assistive technologies and search engines will use this link text to see what the link is for. So link text like ‘click here’ or ‘more’ gives no meaning.

Also if the link is to something other than another webpage, it can be very helpful to say this within the link text. For example if the link is to a PDF file, adding ‘[PDF Document]’ to the link text will let people know what to expect.

5 Use progressive enhanced design where possible or graceful degradation

These terms are similar in that they both offer backward support for older technology. However, their approach is different.

Progressive enhancement is where you start with something that will work anywhere and then check for support of newer technology before using it. Where as graceful degradation is when if something is not supported you either give information about why and what is required before it will work or offer a more basic alternative.

You can read this article Graceful degradation versus progressive enhancement to see an example.

6 Separate content from style

The very early days of web technology, some basic styling like text size and colour was placed in the HTML code. In today’s web technology it is no longer required to do this. Now we have something called CSS (Cascading Style Sheets).

This allows us to just place our content in the HTML code and put all the styling in the CSS. By doing this it makes it easier to maintain and also allows assistive technology have some control over the styles. This can help people with low vision or people with dyslexia.

I generally advise that images used purely for decoration also be placed in the CSS and not in the HTML to help prevent any confusion over the purpose of images. Using null alt text may leave some people who may not be able to see them, wonder what the purpose of the image is. Placing alt text like * or decoration, may distract from the flow of content and again cause confusion.

7 Always use text to support the use of icons

When using icons to help identify something like a PDF document, make sure that it also has text that does the same thing. There are different ways of doing this from using images and alt text within the HTML content. To using custom fonts or images within the CSS and either visible or only screen reader visible text.

Screen reader only visible text is when it is not visible on the screen but screen reader software can access it and read it out.

There are a few ways people have managed this but the best way I have found is to use the CSS clip property. Some have used a left margin offset. However, this will cause horizontal scrolling for people using a right to left language.

8 Keep page content simple and consistent

There is a phrase known as KIS (Keep It Simple) and it is a great thing to bare in mind when writing or designing WebPages.

If your use of language is hard to read or the amount of information on your webpage is overwhelming, many people will not bother and look else where.

Likewise if your webpage layout and navigation is not consistent or is complicated to follow, again most people will give up and go somewhere else.

For accessibility, pages with large numbers of links, complex structures or inconsistent layout and navigation, will often make it very hard to impossible to use with assistive technology.

9 Don’t repeat yourself (DRY)

This term is often used in development and is good practice to follow in your WebPages. Things like using the same link text for different places will cause confusion and people will simply not know what link goes where.

Duplicating your navigation or content on a single webpage, will often just add to the level of complexity for people using assistive technology.

10 Label your form fields effectively

Assistive technology will use the HTML label tag and modern technology may use ARIA to identify form fields and sections of forms.

If form fields do not have their labels marked up, people who use assistive software like screen reader software, may not be able to use the form.

To conclude

These ten tips are a starting point on some of the most common accessibility issues found in today’s websites.

I hope you have found them useful and please feel free to comment, ask questions and let us know your views.

Bonus Tip

A bonus tip is not to place critical text in HTML title attributes. In most cases, you need not use them at all. The reason is generally this text is only available when using a mouse and if it just duplicates text elsewhere, it may cause some screen reader software to read the text twice.

Accessibility for Voice Activation Software

Have you ever watched Red Dwarf with Holly the talking computer and wanted to talk to your computer? For some people talking is their only way to use a computer.

What is voice activation software?

Voice activation software has advanced voice recognition that can listen to your voice through a microphone and convert this to computer instructions. It has evolved from simple sound detection to being able to understand words in multiple languages.

You will find it today being used on mobile phones such as Apples Siri to specialised assistive software on computers. Dragon Naturally Speaking, is probably the most popular voice activation software currently available.

How does web accessibility impact voice activation software?

If you have audio automatically play on your site, it can make it difficult for someone using voice activation to give voice commands. This making it hard to do anything while the audio is playing.

It takes more time to perform any task using voice activation, so moving through hundreds of links can be more trouble than its worth.

If there are little or no structure tags on a webpage, it can be very hard and slow to move and find information. Structure tags are things like headings and html5 section tags with ARIA roles.

You can read more about headings in the article Get started with Structured Headings and I will be covering ARIA in a later post.

Having timed restrictions such as only allowing people a limited time to perform a task may mean that its impossible to use with voice activation software.

Who will use voice activation software?

This started out as a very specialist software for people with physical limitations that prevent them from using a keyboard or mouse.

As the technology evolved it has moved into main stream products and now is used in many mobile devices.

Anyone may use voice activation software for any number of reasons from literacy difficulties to severe physical limitations. Some people may use it simply for their convenience over touch screen keyboards.

Things to note

It is important to remember people may use more than one assistive technology at the same time. It may be used with a screen magnifier or screen reader or other assistive technology.

You should also not assume anything about the people who may use voice activation software. It can be someone using it for better productivity or someone with multiple severe physical impairments.

Understanding how to build device independent websites can help improve peoples experience who use assistive technology. You can read the article A Little Accessibility Guide to Device Independence to learn a little about this.

Have your say

  • Do you use or ever seen voice activation software being used?
  • Have you ever used Siri or similar voice activation on a mobile device?

Why not share your experiences of voice activation software or ask us a question.