IS READSPEAKER COMPLIANT WITH ACCESSIBILITY STANDARDS, LIKE WAI FROM W3C? White paper December 2010 ReadSpeaker, Page 1 of 5
Introduction We are often asked this question. Are you compliant with or supporting accessibility standards? Such as W3C s Web Content Accessibility Guidelines (WCAG 2.0) or more local standards? The short answer? YES! You might also be interested in the long answer: In fact, the ReadSpeaker services and accompanying documents are very well aligned with all 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. In this white paper we summarize the facts aligning ReadSpeaker with the four accessibility principles from WCAG 2.0: Perceivable, Operable, Understandable and Robust. We also provide a short question and answers (Q&A) at the end for the questions we get asked most frequently on this subject. Perceivable The ReadSpeaker implementation code, that is provided by us to the website owners, 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 The ReadSpeaker implementation code utilizes 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 practices for button and player placement yielding consistent look and feel and predictable behavior across different websites. ReadSpeaker UI components are developed based on user input and years of experience to ensure an easy and clear language understandable for as many humans as possible. ReadSpeaker, Page 2 of 5
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 utilizing 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 for 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. Conformance When a WCAG compliant website adds the ReadSpeaker functionality according to our delivered documentation, the site keeps its original conformance level of A, AA or AAA. No partial conformance will arise. The ReadSpeaker implementation code follows all relevant sufficient and advisory techniques for the used technologies, including CSS, Flash, JavaScript, server-side scripts and HTML to satisfy all defined corresponding success criteria. ReadSpeaker services are never activated automatically on a website. They are always triggered by user actions to guarantee minimal interference with ordinary usage of our customers websites. Since we are often asked questions on topics relating to accessibility, we have put the most frequently asked questions in the Q&A section underneath. Q & A Why is aligning with standards important? Conforming to accessibility standards is of paramount importance for all website owners. And therefore all functionalities provided on websites should also be aligned with this. This principle is something the ReadSpeaker company and the people behind ReadSpeaker have adopted from the inception of our company back in 1999. A further reason is because some of our own staff are visually impaired. ReadSpeaker, Page 3 of 5
Do you guarantee that implementing the ReadSpeaker html code will conform to the guidelines? The implementation code we deliver when you are implementing will out-of-the-box validate in 99,9% of cases. In the other few cases, reason might be because we and the customer want to support a broader range of browsing devices to give our users more freedom in what they like to use. However, there is never a guarantee, since the actual implementation on the website is not in our control. Unfortunately such a guarantee from our side is simply impossible. Only the website owner can make sure that the implementation conforms to guidelines. As an example: if you forget to put an Alt-text on the listen button (a descriptive text that appears when hovering with the mouse over button) then this would already provide a problem in validation. Does implementing ReadSpeaker guarantee that your website is fully accessible? No, of course not. To conform to the guidelines as such, you have to see to it that all aspects of your website are in line with the accessibility standards. The reason for adding speech as functionality is not found in guidelines, but in a genuine need of your target group, being people with light to moderate reading disabilities. These people, having mild vision impairment, dyslexia and/or who have trouble reading and writing compose some 20% of the adult population. And for them, a reading function is a helpful tool to better understand (longer) texts on web pages. So it DOES help in making the website more accessible for a specific (and large!) target group. Does ReadSpeaker increase accessibility more than downloadable solutions or screenreaders? Though people often ask this question, the question as such is non-sensical. ReadSpeaker is NOT meant to be a solution for people with severe reading disabilities, such as the blind and severely dyslectic people. Screenreaders are EXACTLY meant for people for people with severe reading disabilities. Downloadable solutions are somewhere in between. Our own experience, based on usage statistics of thousands of websites which have been applying different solutions with different levels of complexity/functionality, shows that as soon as a speech functionality is more than one click away, usage drops by at least a factor of 10 but sometimes even up to a factor of 100...! I get an error when validating my website against W3C and the error relates to the ReadSpeaker code. What do I do? The first thing is to review whether you have implemented the exact code you received from us, and not changed it. Then still you might have very valid reasons for changing the code. In that case, always contact our support department (support@readspeaker.com) and they can help you locate and fix the problem! In our experience of over 10 years, we have never encountered a situation, no matter how custom or specific, where we did not find a solution that was workable. ReadSpeaker, Page 4 of 5
How about the guidelines that are specific to my country. Do you guarantee compliance with those guidelines and what do I do when I have a problem with validation then? Even though our team can not know the specific guidelines of every country, our experience is that mostly there are no specific issues. And if issues arise, they can as a rule be easily dealt with. So you can say that you comply with guidelines, but why should I believe you? Can you give me some proof? Well, we do not have to prove that ourselves, but our customers are the living proof of what we say. There are literally hundreds of websites that validate against the W3C standards and have ReadSpeaker implemented on them. Just to give some examples: www.leeshandicaps.nl www.lafarge.com www.upplands-bro.se www.lulea.se ReadSpeaker, Page 5 of 5