The requirements of Web Content Accessibility are focused on two things – presentation in an accessible visual form and other forms (commonly speech).
We provide a rendering capability for the users of PDF format documents by using toolkits that, as closely as we are aware, render the original PDF document accurately on screen, and in printed form where that is relevant. We are never the creators of the documents so we cannot impose standards on publishers using our products, nor can we determine how those documents will be rendered on the different platform formats that are supported – PC, Mac, iOS, Android, browser. These all have quite different presentation form and format considerations, but the responsibility for choosing an appropriate form and layout remains with the publisher.
There are alternative accessibility tools using sound for rendering documents. Integrating with a tool such as that creates two significant security problems that publishers are unhappy about. Having an unprotected third party code source in our Viewers creates the opportunity for an attacker to hack the point at which we hand control of the raw pdf to them for rendering into sound, and thus exposing the raw source also to the hacker. We take steps to prevent this kind of attack in our own products because we are able to do so, but deep integration is needed before we could be confident that our security approach would be effective. So for the time being we do not offer that kind of integration.
Our products have met market acceptance by such organizations as the American Psychological Association, who address this kind of requirement very carefully.