Microdata is part of the WHATWG (Web Hypertext Application Technology Working Group) HTML Standard, and its primary purpose is to provide a simple way to deliver structured data. To put that another way, it’s a simple tool for providing machine-readable tags to HTML elements — and when used properly, it can make the internet more accessible for some people with disabilities.
However, microdata has limitations. Below, we’ll discuss a few considerations to keep in mind when employing HTML microdata.
Why do websites use HTML microdata?
HTML is a universally recognized coding language with a wide vocabulary, and most website elements can be easily defined with semantic HTML alone. However, rich or dynamic content may include elements that have no standard HTML identifier.
For example, let’s say you operate an ecommerce website that includes product reviews. A user would be able to view the page and determine that the product reviews are written by other shoppers, but unless you have a clear signal within the HTML that says, “this is a product review,” web browsers and search engines can’t programmatically determine where the reviews begin and end. Microdata uses widely available vocabulary (such as Schema.org markup) to identify those complex elements.
The main goal of microdata is to deliver metadata to search engines like Google and Bing, but some web browsers can adjust the way that they display data by referencing your microdata code. For instance, many browsers now have a “Reader Mode" that removes styling and displays content as simple text. Microdata can be used to adjust the presentation of content in Reader Mode.
Many people with disabilities may prefer a simple, straightforward presentation of text, so we recommend reviewing content in Reader Mode on Safari, Firefox, Brave, or another browser that supports the feature.
Microdata isn’t related to WAI-ARIA
While structured data can provide more context for web browsers, it is not a substitute for WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications).
WAI-ARIA is a specification designed to support accessible web applications. Like microdata, it provides semantic definitions for on-page elements that are not natively defined in HTML. However, ARIA is specifically intended for improving the experiences of people who use assistive technologies such as screen readers and eye tracking devices.
WAI-ARIA is more widely supported by assistive technologies than structured data — if you’re concerned with how your content will work with screen readers and other devices, you’ll want to review your ARIA markup first.
Some important concepts to keep in mind:
- If you’re using microdata, test your markup carefully. Google’s Structured Data Testing Tools can identify errors in your structure.
- When using microdata to change Reader Mode presentation, check your content visually. Does Reader Mode hide navigation tools or other essential elements? If so, you’ll need to make some changes.
- Some screen readers may present content differently if it contains microdata. However, WAI-ARIA usually takes precedence.
- WAI-ARIA should only be used when elements cannot be defined in native HTML. This is the first rule of ARIA usage, and it’s a big one — all internet technologies support standard HTML, but WAI-ARIA support is much less universal.
Microdata can improve your users' experiences, but it isn’t a perfect accessibility solution
The bottom line: Using microdata can help you improve your search engine positioning, and it’s a useful tool for adjusting the presentation of your content in certain situations (such as when users access your site with Reader Mode).
However, you should use native HTML5 to define web elements wherever possible. When you cannot define an element with HTML5, you might decide to use microdata — but you’ll also need to use WAI-ARIA to ensure that your content behaves as expected when accessed with a screen reader.
Implementing WAI-ARIA can be difficult, and improper ARIA usage can introduce new accessibility issues to your website. We strongly recommend working with an accessibility partner when creating web apps and other complex content.
To learn more, contact the Bureau of Internet Accessibility to speak with a subject matter expert.