The ReadSpeaker service and accompanying documents are very well aligned with the major principles of WCAG 2.0. Being compliant has always been of great importance for us and we still also conform to WCAG 1.0.  Here we summarize the facts aligning ReadSpeaker with the four accessibility principles from WCAG 2.0: Perceivable, Operable, Understandable and Robust.

Perceivable

• Provided ReadSpeaker implementation code always uses text equivalents for non-textual content to be presentable in other ways that people might need such as magnification, Braille, speech, symbols or simple language.
• ReadSpeaker user interface components are adaptable and distinguishable, clearly separating layout and structure, always choosing high contrasts and media-independent constructs, to enable presentation in simpler layout without loss of information and structure.
• ReadSpeaker provides implementation code containing a description of the purpose of the button and what will happen when the user activates it.

Operable

• Provided ReadSpeaker implementation code utilise all available constructs for being operational from both keyboard-like and pointing devices, thereby allowing assistive technology and UAAG-compliant browsers to be used to give the user full control over the ReadSpeaker user interfaces.

Understandable

• ReadSpeaker provides best practises for button and player placement yielding consistent look and feel and predictable behaviour across different websites.
• ReadSpeaker UI components are developed based on user input and long experience to ensure an easy and clear language understandable for as many humans as possible.

Robust

• Customers can choose specific ReadSpeaker implementation code validating against all known HTML and XHTML document types to match the document type used on their website. It follows all recommendations in the specifications, fully utilising the principles of unobtrusive scripting, HIJAX, graceful degradation and progressive enhancements.
• The provided ReadSpeaker implementation code is carefully designed to ensure maximum forward compatibility with current and future technologies. Since current technology was the future technology of some years ago, ReadSpeaker takes this even further and provide extensive fallback mechanisms to work seamlessly with yesterdays technology, thereby also being backward compatible. Device independence makes it work.

Graceful Transformations and Unobtrusive JavaScripts

This a follow-up post to our views on accessibility and speech-enabling services for all. Note that some code examples may be deprecated but the underlying principles that are illustrated still apply.

Browsers are in their nature both forward compatible and backward compatible. The forward compatibility comes from the built-in design that attributes and elements not understood by the browser are skipped and page rendering continues with the rest of the content. This makes it possible to provide fall-back content inside elements and have this content rendered only if the surrounding content is not renderable by the current browser. Similarly, extra information can be put in attributes and that information can be used only by dedicated software. An image can have both an ALT attribute and a TITLE attribute and if they exists simultaneously, different softwares can use whichever they want.

Also, audio can be embedded in a web page using the OBJECT element, and inside that element the non-standard EMBED element can provide the same audio. In the accompanying NOEMBED element, a direct link to the audio can be provided. This means that the same code will work in all browsers, except the ones that misbehave and try to render both at once. This is one example of graceful transformation. Every visitor will be able to listen to the audio but some might need to click on the link and the different players used to play the audio might vary for different computers, but still there will always be audio.

Another principle that comes naturally with graceful transformation is the use of JavaScripts in an unobtrusive way so that non-javascript environments are not interfered. Still, JavaScript environments can benefit from the extra functionality. This means that we honor techniques like HiJax where Ajax is used to speed up the user interface but if the corresponding links are clicked, the page reloads and displays the intended information.

ReadSpeaker services will always provide basic functionality without requiring scripts. Every component in a web page can as we see it be divided into basic functionality and extended functionality. Basic functionality can for example be a search function where you can search and after clicking a button browse results. Improved functionality with scripts could eliminate the extra button click and incrementally show suggestions, or even hit counts, while still typing the query. Another example is a drop-down for selecting languages, and updating the view on-the-fly, where a NOSCRIPT alternative providing a “Change” button is the small but important step needed to make a service fully usable instead of unusable for certain users in certain technical environments under certain conditions.

If the code we provide is integrated appropriately, the behaviour is that users with JavaScript might see a player showing up in the page while the audio is played. Users without JavaScripts will get the audio played by their standard media player. Instead of providing code like

<a href=”" onclick=”playAudio(‘sound.mp3′); return false;”>Listen</a>

or even

<a href=”javascript:playAudio(‘sound.mp3′)”>Listen</a>

it is much better in all aspects to write

<a href=”sound.mp3″ onclick=”return playAudio(this.href);”>Listen</a>

The script and the link share information so no inconsistencies can occur. In fact, the forward compatibility of browsers even makes a NOSCRIPT alternative unnecessary. Later we indicate how this can be rewritten to validate if decided.

Another example is to differentiate settings that requires JavaScript from those that don’t. If the user wants to change the font of the text that is currently read as well as the speed of reading, it is accepted that the setting that changes the font requires Javascript since the functionality to change fonts on the fly will require it, but it would be against accessibility guidelines to also require JavaScript for changing the value of the reading speed since producing audio in different speeds is not done by the JavaScript.

This post is a follow-up to to our views on accessibility.

Device Independence

When developing our web based text to speech products, we pay special attention to terms such as cross-platform and device independence. Supporting as broad spectra as possible of different kinds of devices and versions of software or operating systems give users the greatest freedom and flexibility to choose what suits them best and use our services in the most advantageous ways. Some of our users are extremely advanced and up-to-date using the latest technology with a fast computer and large screen. They may even use our services for purposes we didn’t have in mind when we developed our solutions.

Others use our services from mobile devices with small screens or low bandwidth. In fact they share much of their user experience and conditions with visually impaired users using magnification software or braille displays and therefore only can consume small amounts of information each time. The low bandwidth can also be because they live in places where Internet connections are not that fast yet. It is our goal that the same product shall be usable and provide good service everywhere, from game consoles, mobile devices, text-based terminals, to top modern desktop computers running the latest of everything, even software that didn’t exist when our development took place. Forward compatibility is as important as backward compatibility.

Introduction

This post and and other subsequent ones will describe the accessibility policy applied for web services developed by ReadSpeaker. It covers our definition of what we mean with accessibility and exemplify how our web based products  comply to this view. Further it discusses how our view conforms to our interpretation of different existing international accessibility standards with emphasis put on web accessibility standards,  especially the ones from the W3C. In short, concepts like “graceful transformation”, “open standards” and “device/platform independence” are of key importance to us. Another important principle is universal design which means that we should not assume anything about the end-users using our products, or under what situations or circumstances they are using it.

(more…)

When we deliver our implementation instructions to our customers, we include documentation on tips of how and where to best place our Listen Button.

As our service differs substantially from traditional tools for text content on websites (such as print, email and/or share options), it is essential to implement ReadSpeaker in web pages in such a way that it is clearly noticeable as an option to use. Yet it should blend in with the overall look and feel of the site. In other words, the implementation should be just right, not overbearing, but also not hidden away so that users can immediately activate the ReadSpeaker listen function.

Over the years we have been able to measure, by usage statistics, which sites are successful with ReadSpeaker and which are not. By taking a closer look at both successful and unsuccessful sites, we have been able to come up with some best practices regarding the Dos and Don’ts when implementing ReadSpeaker Listen Buttons.

(more…)

I attended some weeks ago the 4th European eAccessibility Forum organised by BrailleNet. BrailleNet have just published the proceedings. The conference was of very high quality and I particularly enjoyed the hands-on experiences of some speakers on the challenges of maintaining accessibility standards on their web sites. You can also listen to the proceedings thanks to our ReadSpeaker docReader product in action.

With 10 years of experience in speech enabling the web, it is more than time to broaden the scope than just making content speak on the web and in mobile phones. In these 10 years, as you all know, the web has gone through a number of dramatic changes. From being all about information, it is now about transaction, interaction and socializing. How can web based speech enabling improve these areas? To start with, text is still the problem to a lot of people. Statistics about reading difficulties for example have not changed just because the web has moved forward. Actually, the more that day to day activities get online, the greater the digital divide gets. Exclusion rather than inclusion. That doesn’t feel so 2010.

Sure, speech enabling the web is not the answer to all questions and is not the answer to all prayers, but it sure is a means in reducing the digital divide.

On-line banking and other financial services, government and company e-Services, E-commerce, surveys etc all interact with the users with some kind of online form where they can exercise various tasks whenever they like. Apart from being very convenient for the user, it is also a cost saver for the organization offering these services. Automated processes, case handling systems, online customer support services make a large number of organizations more efficient. However, have they made all necessary efforts to make the front end as usable and accessible as possible?

Not making a form accessible and usable is as wise as putting a 1,76 meter tall and 0,48 meter wide door 50 centimeters from the ground as the only entrance to the supermarket. With average height, width and gymnastic skills you can come in, and if not, you don’t.

Since we know that speech enabling does help a lot of people, we developed a prototype of what came to be ReadSpeaker formReader. We implemented it on a few forms (e-services) at a municipality website in Sweden. We also gathered a test group with people from different disability groups (plus a few elderly and some non-native speaking persons). After the test phase, we did as we normally do when developing a new product, we went back to the drawing table incorporating the results from the user tests. Speech enabling forms helps. To be able to have audio prompts that tell you what to fill in and a voice that reads back what you have written/chosen proves to be very useful. With more people being able to fill out the forms themselves, and fill them in accurately (thanks to the “proof listening”), the organization offering the service gets a better value for their investment.

And since formReader works pretty much like a screen reader, the requirements on the forms are the same. Meaning that they should be properly coded according W3C/WCAG guidelines.

During the implementation of the formReader on the municipality website, a couple of easily solvable accessibility issues became very obvious and were easily corrected by the municipality web developers. So the result was, regardless if you chose to activate formReader or not, a better and more accessible web form.

CSUN2010_ReadSpeaker_formReader_Presentation

Techshare Logo

I just got the message that I have been offered a presentation slot at this year’s Techshare Conference in London hosted by the RNIB at 3.30pm on Friday September 18. I will speak about the new web standard for Accessible Rich Internet Applications (ARIA) and I will be presenting our current work for speech enabled Government eServices. A way to make it possible for more citizens to participate in the digital community, and create better reach for government web applications.

Techshare is a series of pan-disability assistive technology events, hosted by RNIB (Royal National Institute of Blind People), which aim to develop this exciting and innovative field to support end users.

Assistive technology can be defined as any item, equipment, product or service which increases, maintains or improves functional capabilities of individuals with disabilities.
Techshare conferences are supported by partners who work with us to develop and deliver the conference, providing a valuable contribution to, and steer on, the content of the event.

We have decided to sponsor the European Accessibility Forum held on the 27th of March in Frankfurt Germany.

Web accessibility is of great importance not only for people using screen readers and other assistive technology but also for everybody else. Adopting and practicing the web standards is key to make web content accessible for more people regardless of device, browser type and operation system.

When I attended and spoke at the CSUN Conference on Disability 2009 in Los Angeles last week I had the opportunity to talk to the authors of the WCAG 2. I was glad to see that speech enabling is finally seen as enhanced accessibility, especially to make the text content more understandable. So in short; implementing a ReadSpeaker service on your website can help you to conform to some of the guidelines.

If you are attending the European Accessibility Forum in Frankfurt and would like to meet up with me, please contact info@voice-corp.com to set up a meeting.

See the Conference website for more information about the conference: http://eafra.eu/

I will be particpating in a panel about accessible online text content and electronic books for people with disabilities at the most important French book fair called the “Salon du Livre” on March 17 from 11h30 to 13h.  The audio channel for electronic books is a hot topic right now with all the noise being made by Amazon’s Kindle 2 launch.  I think that it speaks for itself that a major player like Amazon is introducing text-to-speech to facilitate access to digital text content and shows that the audio dimension is becoming a must have for many platforms.