Structured Data dan Accessibility: Dua Layer yang Punya Fungsi Berbeda

Website bisa punya JSON-LD yang sempurna dan tetap menyiksa user screen reader.

Website juga bisa sangat accessible dan punya structured data yang berantakan.

Kedua hal ini sama-sama berkaitan dengan semantics.

Itulah yang membuat orang sering mencampur.

“Kan sudah semantic markup.”

Semantic yang mana?

Untuk search/structured data?

Untuk document structure?

Untuk accessibility tree?

Tiga hal ini saling berhubungan, tetapi tidak identik.

Structured data seperti Schema.org membantu machine consumers memahami entities dan relationships:

Article.

Person.

Organization.

Product.

Offer.

Dataset.

Breadcrumb.

Accessibility menggunakan semantic HTML, accessible names, ARIA ketika dibutuhkan, keyboard behavior, focus, contrast, media alternatives, dan prinsip lain untuk memastikan orang dengan disabilities dapat menggunakan web content.

Schema.org tidak menggantikan WCAG.

ARIA tidak menggantikan Schema.org.

`alt` text tidak sama dengan `image` property di JSON-LD.

Dan menambahkan Organization schema tidak membuat menu bisa dipakai keyboard.

Ini basic separation yang perlu ada di setiap technical SEO roadmap.

Accessibility Berangkat dari Manusia

W3C Web Content Accessibility Guidelines, WCAG, menjelaskan bagaimana membuat web content lebih accessible untuk people with disabilities.

WCAG 2.2 adalah Recommendation W3C dan mencakup banyak area:

Perceivable.

Operable.

Understandable.

Robust.

Practical implementation menyentuh:

Text alternatives.

Captions.

Headings.

Keyboard.

Focus.

Forms.

Errors.

Color contrast.

Target size.

Authentication.

Consistent navigation.

Accessibility bukan “screen reader SEO.”

It is human rights/usability/engineering discipline.

The primary beneficiary is user.

Machine semantics are part of implementation, but not primary objective.

Structured Data Berangkat dari Deskripsi Machine-Readable

Schema.org gives shared vocabulary to describe things.

Example:

Article author Person A.

Product offered by Merchant B.

Dataset created by Organization C.

WebPage mainEntity Organization D.

This is useful for machine consumption.

Google Search supports selected types for rich results/features.

Other consumers may use Schema.org.

But JSON-LD usually doesn't alter keyboard navigation.

Doesn't create accessible name.

Doesn't add label to input.

Doesn't make modal focus trap correct.

Doesn't ensure image has useful alternative text.

Different layer.

Semantic HTML adalah Titik Pertemuan yang Sering Disalahpahami

W3C WAI recommends marking content structure using appropriate semantic elements.

Heading should be heading.

List should be list.

Navigation should use semantics.

Button should be button.

This semantic structure can be exposed through accessibility APIs/tree and help assistive technologies understand page.

SEO teams also like semantic HTML because it creates clear document structure.

Browser agents may inspect DOM/accessibility tree.

So there is overlap in benefit.

But semantic HTML is not same as Schema.org.

`<article>` tells document structure.

Article JSON-LD describes a CreativeWork entity with author/date/publisher and other properties.

Both can exist.

One doesn't replace another.

Example:

`<main>`.
`<article>`.
`<h1>`.
`<button>`.

Accessibility/document semantics.

JSON-LD:
Article.
Person.
Organization.

Structured entity semantics.

Think two maps of same page with different jobs.

ARIA Punya Job Khusus

WAI-ARIA helps make dynamic content and advanced UI controls more accessible.

It can express:

Roles.

States.

Properties.

Relationships.

Example:

`aria-expanded`.

`aria-controls`.

dialog role.

tab semantics.

Accessible name.

This maps interface meaning to assistive technologies.

ARIA is not an SEO entity vocabulary.

Don't put:

role="organization"

and think search understands Organization.

Don't put Schema.org Person and think screen reader knows a control's label.

Different namespace.

Different consumer.

Different problem.

Native HTML Often Better for Accessibility

W3C guidance repeatedly emphasizes proper semantic elements.

Use actual button instead of clickable div with custom ARIA if native control fits.

Why?

Browser already understands behavior.

Keyboard.

Focus.

Accessibility mapping.

Custom controls require more work.

This matters for agentic web too.

Google's 2026 generative AI guide mentions browser agents may inspect DOM and accessibility tree.

A native button with clear accessible name can be easier to operate than ambiguous div.

Again:
not a ranking claim.

It's interface legibility.

Accessible web structure has broader machine-operability benefits.

But accessibility should not be justified only because AI agents may like it.

Users matter first.

Alt Text vs Image Schema

Image has:

Visual role.

Accessibility text alternative.

Structured identity/metadata.

These overlap but are not same.

`alt` should communicate function/content to users who cannot see image, depending context.

ImageObject schema can describe image metadata.

URL.

Creator.

Caption.

License.

Content URL.

Structured properties don't automatically become screen-reader alternative.

If image has no alt:
ImageObject doesn't fix accessibility.

If alt is stuffed:
“best AI SEO GEO agency Jakarta Indonesia 2026”
bad accessibility and bad writing.

Alt text should serve user context.

Schema properties serve machine data description.

Don't copy blindly.

Breadcrumb Schema vs Accessible Navigation

JSON-LD BreadcrumbList valid.

Visible breadcrumb is a set of plain spans not links.

Poor.

Or breadcrumb nav lacks accessible label.

Or focus confusing.

Structured breadcrumb can support Google Search representation.

Accessible breadcrumb needs HTML/navigation semantics.

Often:

`nav` with label.

Ordered list.

Links.

Current page indication.

Exact pattern depends implementation.

Do both.

One source of hierarchy can power both visible nav and JSON-LD.

Shared data, different output.

This is ideal.

FAQ Schema vs Accordion Accessibility

Article 271 explained FAQPage.

Now UI side.

FAQ accordion must work with keyboard.

Button toggles answer.

Expanded state conveyed.

Focus reasonable.

Text readable.

If developer builds clickable `<div>`:
mouse works.
keyboard maybe not.
screen reader state unknown.

FAQPage JSON-LD can still validate.

That's perfect illustration.

Search schema PASS.

Accessibility FAIL.

Need separate tests.

Validator tools shouldn't be conflated.

Rich Results Test doesn't test WCAG.

Accessibility checker doesn't validate Product schema.

Use correct tool.

Form Schema Tidak Membuat Form Accessible

Schema.org Action/EntryPoint might describe an action.

Form still needs:

Label.

Instructions.

Error identification.

Focus.

Keyboard.

Required state.

Autocomplete where appropriate.

Accessible status.

Security.

An AI-agent use case may care too.

But accessibility requirements are human-centered.

Don't say:
“potentialAction makes booking form machine accessible.”

No.

It describes potential action.

Form semantics determine interaction.

Content Hidden for Schema vs Accessibility Tree

Interesting conflict.

Google structured-data rules generally say structured content should correspond to visible content.

Accessibility can have visually hidden text that is still exposed to screen readers for context.

Example:
visually hidden label.

That is still user-accessible through assistive technology.

Different notion of “visible”.

Don't interpret structured-data guideline mechanically as:
“Every schema value must be pixels on screen.”

But important factual content should be accessible to users and not crawler-only.

Accessibility often uses visually hidden techniques legitimately.

Need semantic judgment.

Do not remove screen-reader-only labels because “SEO says hidden text bad.”

Accessibility is valid user experience.

ARIA Labels Can Differ from Visible Text

Button visible:
“Search.”

aria-label:
“Search research archive.”

Good.

Machine interacting through accessibility tree may see accessible name.

JSON-LD doesn't.

If schema says SearchAction:
another layer.

Could all align.

But don't auto-generate ARIA labels from SEO keywords.

Accessible names should describe control purpose.

Human task.

Heading Structure Is Not Schema Hierarchy

H1.

H2.

H3.

These organize document.

JSON-LD graph relationships:

isPartOf.

about.

mainEntity.

publisher.

Don't assume heading nesting builds knowledge graph.

And don't use JSON-LD to compensate broken heading hierarchy.

User navigating by headings needs actual headings.

W3C content-structure guidance emphasizes semantic markup because assistive technologies use structure.

A page with `<div class="h2">` styled like heading but not semantic may look fine.

Structured Article schema doesn't fix.

Fix HTML.

Accessibility and SEO Can Share Source-of-Truth

Example author.

Visible byline:
Person A.

Link:
Profile.

Accessible link text:
“Profile Nadia Putri.”

Article schema:
author Person A.

Good.

Location page:
Visible address.

Map link accessible.

LocalBusiness schema same address.

Good.

Product:
Visible price.

Screen reader accessible.

Product Offer same price.

Good.

One truth.

Different representations.

When these layers share source data, drift reduces.

But one generator should not output accessibility attributes mechanically without UX rules.

Shared data.

Separate presentation semantics.

Accessibility Tree Is Not Public Knowledge Graph

Another confusion emerging with AI agents.

Accessibility tree contains:

roles.

names.

states.

relationships relevant to UI.

Knowledge graph contains:

entity identities and semantic relationships.

A button:
role button.
name “Book appointment.”
expanded false.

Organization KG:
provides Service X.

Appointment Action:
maybe target URL.

Different graph.

Browser agent can use accessibility tree to operate UI.

Search/retrieval system can use page content/schema for understanding.

Don't call accessibility tree “AI knowledge graph.”

Technically misleading.

Two layers can be connected through action.

But distinct.

WCAG Conformance Tidak Bisa Disimpulkan dari Schema

No structured-data property:
`accessible: true`

can prove WCAG conformance.

Schema.org has accessibility-related metadata properties used for CreativeWork in some contexts, like accessibilityFeature/accessibilityHazard/accessMode, but those describe accessibility characteristics of resources.

They don't magically certify an entire website meets WCAG.

Conformance requires evaluating applicable success criteria.

Automated tests only cover some issues.

Human evaluation often needed.

Don't publish “WCAG AA” because plugin score 100.

Separate compliance process.

Similarly, structured data validation:
not accessibility certification.

Structured Data Tidak Bisa Menggantikan Text Alternative

A chart has Dataset schema.

ImageObject.

Caption.

But screen reader needs meaningful alternative.

For simple chart:
alt/caption maybe enough.

For complex:
long description/data table.

W3C has guidance for complex images.

If chart conveys conclusion:
ensure non-visual user can access.

Dataset download can be excellent supplement, but not always substitute for accessible summary.

Accessibility means comparable information.

Schema means machine description.

Different acceptance test.

C2PA Juga Layer Lain

Preview next article.

Content provenance.

C2PA.

Structured data.

Accessibility.

All machine-related.

All distinct.

A C2PA Content Credential can show provenance.

It doesn't make asset accessible.

Image alt still needed.

ImageObject doesn't provide cryptographic provenance.

ARIA doesn't sign content.

Layered architecture.

This is why “machine-readable” is too broad a phrase.

Ask:
Readable by which machine for what purpose?

Search?

Screen reader/browser accessibility API?

Agent?

Cryptographic validator?

Commerce feed?

Different contracts.

Testing Stack yang Masuk Akal

For representative page:

HTML validator/lint.

Accessibility automated scan.

Keyboard manual test.

Screen-reader/manual accessibility review as appropriate.

Rich Results Test/structured-data validator.

Semantic schema audit.

Performance.

Security.

Browser-agent test if business use case.

Each catches different failure.

Don't celebrate green one tool as full quality.

A site can pass Lighthouse accessibility checks and still have issues.

A site can pass Rich Results Test and still have wrong schema.

Human review remains.

Governance Owner Juga Berbeda

Accessibility:
Design system.
Frontend.
Content.
Accessibility lead.
QA.

Structured data:
SEO.
Data/entity owner.
Backend/frontend.
Editorial.

Shared:
Content truth.
Semantic HTML.
CMS.
Testing.

They should collaborate.

Not merge responsibilities so no one owns.

Example:
Product price source belongs commerce.
Accessibility ensures price exposed meaningfully.
Schema ensures Offer matches.
SEO monitors Search feature.
One fact.
Different layers.

This is healthy.

AI Agent Readiness Makes Collaboration More Valuable

Agent may read page like browser.

Accessible semantic controls can help.

Structured data may clarify entities/products.

API gives execution.

Authentication protects.

No single team.

If organization starts “agent readiness” project, involve accessibility engineers early.

Not because accessibility is AI optimization.

Because robust semantic interfaces are good for humans and often easier for software to navigate.

But don't hijack accessibility budget with AI narrative.

The business should meet accessibility obligations regardless.

Two Layers, Satu Truth

The cleanest way to see it:

Structured data answers:
“What is this thing?”

Accessibility answers:
“Can this user perceive, understand, and operate this interface/content?”

Product schema:
This is Product X.

Accessibility:
Can user select size without mouse?
Can screen reader hear price?
Can low-vision user see focus?
Can form errors be understood?

Article schema:
Who wrote and published.

Accessibility:
Are headings meaningful?
Can links be distinguished?
Can media be consumed?

Both matter.

Neither substitutes.

The web gets stronger when both are implemented from same content truth.

Do not use one as excuse for the other.

A page isn't “machine-friendly” just because JSON-LD is rich.

A page isn't “fully accessible” just because HTML uses semantic tags.

Quality is layered.

And the most mature technical teams know exactly which layer they are testing before declaring PASS.