Our new beta API will help you assess how well your documents meet accessibility standards<\/h2>\n\n\n\n\n\n<\/p>\n\n\n\n![\"Raymond](\"https:\/\/miro.medium.com\/v2\/resize:fill:88:88\/1*ldF-FsLonNyTUOmQ7cIV_g.jpeg\")
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/a><\/p>\n\n\n\n\n![\"Adobe](\"https:\/\/miro.medium.com\/v2\/resize:fill:48:48\/1*riyFijvwTfGcWNf1guRNtg.png\")
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n![\"\"]()
<\/picture><\/div>\n<\/figure>\nA few months ago, we launched the PDF <\/a>Accessibility Auto-Tag API<\/a>, a powerful tool that intelligently examines your source PDF documents and attempts to tag them by identifying reading order, tables, and more.<\/p>\nWhile this is not meant to be a \u201ccomplete\u201d accessibility solution, it can go a long way in automating a good chunk of the work required to properly make documents more accessible.<\/p>\n
As part of support for this service, today we\u2019re happy to announce the beta release of a new API: the PDF Accessibility Checker API.<\/strong><\/p>\nThis API will take your document and check how well it conforms to accessibility standards. It returns both a human-readable HTML report as well as a machine-friendly JSON result.<\/p>\n
Let\u2019s take a look at how this service operates.<\/p>\n
First and most importantly, at this time the beta for the API is in private<\/em> testing only. That means you\u2019re free to read the docs<\/a>, but using the API requires reaching out to us and describing your use case.<\/p>\nFill out the form<\/a> here and someone from our team will reach out shortly.<\/p>\nSecondly, you cannot use existing credentials to test this API. Once you\u2019ve been approved to kick the tires, create new credentials here<\/a> and use them in your testing.<\/p>\nNote that currently we only have SDK support in Java, but the REST API will work just fine and that\u2019s what we\u2019ll demonstrate here.<\/p>\n
All of the Acrobat Services operate virtually the same via the REST APIs. These new APIs were first introduced in September of last year and the beauty of them is that once you\u2019ve written one integration, you can re-use nearly all of your code for other parts of the service as well. We covered the \u2018flow\u2019 last year (see \u201cAnnouncing the New Adobe Document Services REST APIs\u201d<\/a>) so we\u2019ll only briefly cover it here.<\/p>\nTo use the PDF Accessibility Checker API via REST, first you\u2018ll need to exchange your credentials, a Client ID and Secret, for an access token. Here\u2019s sample code in Node.js:<\/p>\n
In order for the API to scan your PDF, you need to upload it (external cloud storage support will come later).<\/p>\n
This is a two-step process. First, you tell us what kind of file you are uploading. This is done by hitting the assets endpoint with your access token, client ID, and the type of file, in this case, application\/pdf<\/code>.<\/p>\nThis returns an asset record that includes a URL that allows you to upload your binary data:<\/p>\n
Like every other API in the offering, you create a \u201cjob\u201d that includes various arguments dependent on the specific operation.<\/p>\n
At this time, our docs<\/a> cover three arguments. The only required argument is the ID of the asset created earlier. Then there are two optional arguments to let you define a page start and end range. This could be useful in cases where you know that some pages do not need to be checked, or perhaps limit the check to a portion of a large PDF document.<\/p>\nOnce again, here\u2019s sample Node.js code hitting the endpoint to create the job. Notice that on a good result, you get a URL in the Location<\/code> here.<\/p>\nYou can now poll the job to see if it\u2019s done. In this example, we\u2019ve used a simple interval to check the result and return it when it is successful:<\/p>\n
The two-second delay here is mostly arbitrary. In general, the jobs complete after a few seconds so this will only need to run a few times.<\/p>\n
When (successfully) done, the result looks like this:<\/p>\n
Finally, you can download the result. As mentioned above, you get both an HTML report attached to a PDF and a JSON result. You may not need both, but here\u2019s a utility method to grab them and an example of using it:<\/p>\n
Once you have the results, what do they look like?<\/p>\n
First, in the PDF, be sure to open the Attachments panel and double-click on the HTML file. This gives you a report like so:<\/p>\n\n\n![\"HTML]()
<\/picture><\/div>\n<\/div>\n<\/figure>\nIn the screenshot above, you can see a high-level summary and then a detailed breakdown of the issues. Each link goes to a page that gives much more information about the issue.<\/p>\n
The JSON report contains the same information, minus links to educational resources:<\/p>\n
Hopefully, this quick introduction demonstrates just how easy, and powerful, this new API can be for your document processes. The entire Node.js script used above may be found here<\/a>, and of course, can be adapted to any other language via the REST API. Be sure to visit the forums<\/a> with your questions!<\/p>\n<\/div>\n
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/a><\/p>\n <\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n A few months ago, we launched the PDF <\/a>Accessibility Auto-Tag API<\/a>, a powerful tool that intelligently examines your source PDF documents and attempts to tag them by identifying reading order, tables, and more.<\/p>\n While this is not meant to be a \u201ccomplete\u201d accessibility solution, it can go a long way in automating a good chunk of the work required to properly make documents more accessible.<\/p>\n As part of support for this service, today we\u2019re happy to announce the beta release of a new API: the PDF Accessibility Checker API.<\/strong><\/p>\n This API will take your document and check how well it conforms to accessibility standards. It returns both a human-readable HTML report as well as a machine-friendly JSON result.<\/p>\n Let\u2019s take a look at how this service operates.<\/p>\n First and most importantly, at this time the beta for the API is in private<\/em> testing only. That means you\u2019re free to read the docs<\/a>, but using the API requires reaching out to us and describing your use case.<\/p>\n Fill out the form<\/a> here and someone from our team will reach out shortly.<\/p>\n Secondly, you cannot use existing credentials to test this API. Once you\u2019ve been approved to kick the tires, create new credentials here<\/a> and use them in your testing.<\/p>\n Note that currently we only have SDK support in Java, but the REST API will work just fine and that\u2019s what we\u2019ll demonstrate here.<\/p>\n All of the Acrobat Services operate virtually the same via the REST APIs. These new APIs were first introduced in September of last year and the beauty of them is that once you\u2019ve written one integration, you can re-use nearly all of your code for other parts of the service as well. We covered the \u2018flow\u2019 last year (see \u201cAnnouncing the New Adobe Document Services REST APIs\u201d<\/a>) so we\u2019ll only briefly cover it here.<\/p>\n To use the PDF Accessibility Checker API via REST, first you\u2018ll need to exchange your credentials, a Client ID and Secret, for an access token. Here\u2019s sample code in Node.js:<\/p>\n In order for the API to scan your PDF, you need to upload it (external cloud storage support will come later).<\/p>\n This is a two-step process. First, you tell us what kind of file you are uploading. This is done by hitting the assets endpoint with your access token, client ID, and the type of file, in this case, This returns an asset record that includes a URL that allows you to upload your binary data:<\/p>\n Like every other API in the offering, you create a \u201cjob\u201d that includes various arguments dependent on the specific operation.<\/p>\n At this time, our docs<\/a> cover three arguments. The only required argument is the ID of the asset created earlier. Then there are two optional arguments to let you define a page start and end range. This could be useful in cases where you know that some pages do not need to be checked, or perhaps limit the check to a portion of a large PDF document.<\/p>\n Once again, here\u2019s sample Node.js code hitting the endpoint to create the job. Notice that on a good result, you get a URL in the You can now poll the job to see if it\u2019s done. In this example, we\u2019ve used a simple interval to check the result and return it when it is successful:<\/p>\n The two-second delay here is mostly arbitrary. In general, the jobs complete after a few seconds so this will only need to run a few times.<\/p>\n When (successfully) done, the result looks like this:<\/p>\n Finally, you can download the result. As mentioned above, you get both an HTML report attached to a PDF and a JSON result. You may not need both, but here\u2019s a utility method to grab them and an example of using it:<\/p>\n Once you have the results, what do they look like?<\/p>\n First, in the PDF, be sure to open the Attachments panel and double-click on the HTML file. This gives you a report like so:<\/p>\n In the screenshot above, you can see a high-level summary and then a detailed breakdown of the issues. Each link goes to a page that gives much more information about the issue.<\/p>\n The JSON report contains the same information, minus links to educational resources:<\/p>\n Hopefully, this quick introduction demonstrates just how easy, and powerful, this new API can be for your document processes. The entire Node.js script used above may be found here<\/a>, and of course, can be adapted to any other language via the REST API. Be sure to visit the forums<\/a> with your questions!<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/miro.medium.com\/v2\/resize:fit:640\/format:webp\/1*Gam9MigtXSxWy42OkzKyQA.png)
application\/pdf<\/code>.<\/p>\nLocation<\/code> here.<\/p>\n![\"HTML](\"https:\/\/miro.medium.com\/v2\/resize:fit:640\/format:webp\/1*b-wVQz3jOK2u-SKI8ojb-A.png)