An accessibility audit API loads a page, runs it against WCAG 2.1 AA rules, and returns the failures as data. Ours uses axe-core, the engine most accessibility tools are built on, and returns each failure with the affected elements and a plain-English fix.

Calling it

curl "https://seoscoreapi.com/audit/accessibility?url=https://example.com" \
  -H "X-API-Key: YOUR_KEY"

What the response contains

Field What it holds
score, grade Overall result, based on WCAG 2.1 A and AA rules only
summary Rules checked, violations, passes, and checks that need a person
lawsuit_risk A level (high, medium, low, minimal) and the violations behind it
violations WCAG failures, each with its affected elements and a fix
best_practices Good-practice findings that are not WCAG requirements
needs_review Checks the engine couldn't decide, with what to verify by hand
priorities One ordered list: WCAG failures first, then best practices
categories Results grouped by area: images, forms, contrast, keyboard, ARIA and more

Two details matter when the result goes to a client:

  • Best practices never lower the score. A heading-order note is useful, but it isn't a WCAG failure, so it is kept in its own list.
  • "Needs review" isn't counted as a failure. If the engine can't tell whether text over an image has enough contrast, it says so and tells you what to look at.

What automated checks can't find

Automated testing finds a real share of accessibility problems, but not all of them. It can tell that an image has no alt text. It can't tell whether the alt text that is there describes the image. It can't judge whether a page makes sense read aloud, or whether a custom menu is usable with a keyboard in practice.

Use the API to catch what is machine-detectable, on every page, every time. Use a person for the rest. A clean automated result is not a statement that a site is compliant, and the report doesn't claim it is.

Using it across a site

One call audits one page. Templates repeat, so a few pages usually cover most of a site: the homepage, a content page, a form, and any page in the checkout or booking flow.

import requests

pages = ["https://example.com/", "https://example.com/contact", "https://example.com/book"]
for page in pages:
    r = requests.get("https://seoscoreapi.com/audit/accessibility",
                     params={"url": page}, headers={"X-API-Key": "YOUR_KEY"}).json()
    print(page, r["score"], r["lawsuit_risk"]["level"], len(r["violations"]))

Add include=trackers to the same call and the response also lists the third-party trackers on the page, which is useful when the same review covers privacy.

Limits

Accessibility audits have their own monthly allowance, separate from standard audits: 5 on Starter, 20 on Basic, 100 on Pro and 500 on Ultra. A failed audit isn't counted.

More on putting this to work: automating WCAG monitoring and the accessibility audit API page.

Frequently asked questions

Which standard does it test?

WCAG 2.1 Level AA, the standard most accessibility claims in the US refer to.

Is the lawsuit risk level legal advice?

No. It is a summary of which detected failures are the kind most often cited in complaints.

Does it test pages behind a login?

No. It audits pages it can reach without signing in.