When developing web based products that are supposed to be a piece of the accessibility puzzle, such as ReadSpeaker, the product itself must obviously not introduce new difficulties for the users. They need to be made to work everywhere and for everyone, always. How is that achievable? Our approach to this is that we put as much of the intelligence as possible on the server side, and only put what is absolutely needed on the client side (in our case the “client side” is on the website where ReadSpeaker is implemented – not the end user side). And any JavaScript components that are used to increase the user experience for visitors using browsers that support it, we host in the cloud. This way we can make sure that the user experience is the same, or in the worst case similar on all platforms, and we can easily update the cloud scripts as the web evolves. Since most web browsers have support for different techniques and have different abilities to view embedded media (such as audio streams) we can adapt what is sent from the server-side fully depending on what kind of device and browser the end user uses. And by using obtrusive scripts with graceful transformation, we make sure that even the simplest technology used on the client side can also get the speech back. Basically, it needs to be able to provide the core functionality even without requiring JavaScript support or possibilities to embed rich media. You never know what the visitor might use to browse your site or use the online product. Even though the majority uses the Top 5 browsers I would say stopping there just isn’t enough. It does not make sense to lock people out for no or the wrong reasons. A reason should never be “If you can’t have it all you shouldn’t have anything”. By developing the core functionality of a web based product using the simplest possible pieces and following the specifications, you can ensure maximum possible visitors/users. Additional UI features and user experience bells and whistles should be added on top of it, like the ketchup on a hot dog. The hot dog is totally eatable also without the add-ons, even though it wouldn’t be as nice, it makes a very small difference if you are really hungry! Apart from developing a platform and browser independent solution, there are also a number of others important aspects of creating an accessible web product. The user interface should be keyboard accessible, as intuitive as possible and in general be very easy to use. In the ReadSpeaker case, we make sure that the speech is always only ‘One Click Away’. Web products and web applications that provide flexibility for the customer on how they are implemented can sometimes have some drawbacks. With flexibility also comes responsibility. It can become difficult for a company developing these kind of product to always guarantee the functionality if implementers with low skills in web accessibility get too creative. The implementation instructions we provide to our customers guarantee that they will be as end user friendly in general and as accessible as possible in particular. Apart from the technical side of things, nothing beats end user tests. We try to gather a relevant number of people from the intended target groups and observe them while using the service and following the tests ask them number of questions. Then, we often go back to the drawing table and incorporate the missing pieces. One of the difficulties is always to combine the requirements from very different user groups to get to a “design for all” solution at the end, but once there, If you make sure that it is functional for the users with the greatest difficulties; it is then usually the case that it is very usable for everybody.