Technique · schema.org · JSON‑LD · Microdata · Open Graph
Structured data, JSON‑LD and rich snippets
Structured data is information about a page written in a standardised vocabulary (schema.org) that a machine can read without guessing: "this is a product, it costs 199 zł, it is in stock, it is rated 4.7". Search engines show it as rich snippets (enhanced results with price, stars, FAQ, breadcrumbs), AI assistants quote it as fact, and screen readers and other tools rely on the same idea — explicit structure instead of appearance. The act does not require it. But a page with good structure for people usually has it for machines too — and vice versa.
Three formats, one vocabulary
| Format | What it looks like | When |
|---|---|---|
| JSON‑LD | a <script type="application/ld+json"> block in the <head> or <body>, independent of the HTML | recommended by Google; easiest to maintain; does not touch the page's accessibility (a screen reader does not read it) |
| Microdata | itemscope, itemtype, itemprop attributes on HTML elements | older shops; ties the data to visible elements, so it is harder for what is shown and what is declared to drift apart |
| RDFa | vocab, typeof, property attributes | rare outside the public and publishing sectors |
Plus Open Graph (og:title, og:image…) and Twitter Cards — not schema.org, but the same goal: a link preview in messengers and social media. This site has both JSON‑LD and Open Graph — view the source.
Example: a product in a shop
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Lumen 7 e‑reader",
"image": ["https://shop.example/img/lumen-7.jpg"],
"description": "A 7\" e‑reader with front light and text‑to‑speech.",
"sku": "LUM-7",
"brand": { "@type": "Brand", "name": "Lumen" },
"offers": {
"@type": "Offer",
"url": "https://shop.example/lumen-7",
"priceCurrency": "PLN",
"price": "699.00",
"availability": "https://schema.org/InStock",
"hasMerchantReturnPolicy": { "@type": "MerchantReturnPolicy",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 14 }
},
"aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.7", "reviewCount": "128" },
"accessibilityFeature": ["readingOrder", "textToSpeech"],
"accessibilitySummary": "Voice‑operated menu; Polish text‑to‑speech."
}
</script>
The last two fields are no accident: schema.org has the properties accessibilityFeature, accessibilityHazard, accessibilityControl and accessibilitySummary. For products covered by the act (e‑readers, computers, terminals) this is a ready‑made place for the accessibility information that art. 18(1) requires a shop to provide — readable by the customer and by the search engine.
Types worth having
Organization / LocalBusiness
Name, logo, address, phone, opening hours, tax id (vatID), social profiles (sameAs). On the home page and in the footer; the basis of the "knowledge panel" in results.
WebSite + SearchAction
The site's name and a search box in Google results (sitelinks searchbox).
BreadcrumbList
The navigation path in the search result instead of a raw URL. Matches visible breadcrumbs — which are also good WCAG 2.4.8 (AAA) practice.
Product + Offer + AggregateRating
Price, availability, ratings, returns, shipping (shippingDetails). Google requires consistency with what the page shows.
FAQPage
Questions and answers visible on the page. Google limited their display to government and health sites (2023), but AI assistants and other search engines still read them. Our FAQ has FAQPage.
Article / BlogPosting
Author, date, image, publisher — for blogs and guides. Every page of this compendium has Article.
Event, Course, Recipe, JobPosting
Types with their own rich results: dated events, courses, recipes with times, job offers in Google Jobs.
VideoObject
Thumbnail, duration, transcript (transcript) — the last of which is at the same time a text alternative under WCAG 1.2.
The rules that decide whether it works
The data must match what is shown
Google penalises ratings that are not on the page, prices other than the visible ones, FAQ hidden from the user. It is the same rule as in accessibility: structure describes content, it does not replace it.
One main object per page
A product page is one
Product; a product list is anItemListwith links, not 40 full products.Valid JSON
One comma too many and the whole block is ignored without a message. Our checker parses every JSON‑LD block and reports the unparseable ones (rule pad-structured-data).
Test
Google's Rich Results Test and the Schema Markup Validator (validator.schema.org) show what was read and which fields are missing for a rich result.
Don't invent fields
The schema.org vocabulary is closed; unknown properties are ignored. When something is missing, use
additionalProperty.
What this has to do with the act
Directly — nothing: neither the EAA, nor the Polish act, nor WCAG require schema.org. Indirectly — a lot:
- The same discipline. A page where the price is text (not an image), breadcrumbs are a list, the FAQ is headings and paragraphs, and the product has a name, description and photo with an alternative — is accessible and ready for structured data. A page built of images and divs is neither.
- Product accessibility information (art. 18(1)) has ready fields in schema.org that comparison sites and search engines understand.
- Statement and terms.
WebPagetypes withaccessibilitySummaryand an "Accessibility" page linked fromOrganizationmake the art. 32 information easier to find — also for the authority. - AI assistants increasingly answer questions about a shop from structured data and the
llms.txtfile. This site has both.
What the checker shows
In the page profile the report lists the schema.org types found (e.g. Organization, Product, BreadcrumbList), the number of blocks and any unparseable ones, and the e‑commerce signals detected from, among others, Product/Offer. A lack of structured data is marked as information, not as a breach — because it is not one.
