Plain Old Semantic HTML: A Perfect Basis for Accessibility

To create web content that works for as many users as possible, websites need structure. Not every user can perceive content visually — and not every user will get the same experience from visual-first content. 

Screen readers and other assistive technologies work most effectively when a web page provides information about its HTML structure. Structure allows software to offer features that enhance the user experience. For example, a user can scan through an article to find subheadings, links, and other information quickly. 

So, what’s the safest way to provide semantic information about the structure of your content? Plain Old Semantic HTML (or POSH, for short). 

The Basics (and Importance) of POSH for Accessibility

The acronym POSH was coined in 2007 and quickly gained popularity with web designers and developers (after all, developers love a good acronym). The concept is simple: HTML should be structural, not presentational. Elements of a website should be programmatically described using native HTML wherever possible, since all browsers — and all assistive technologies — support native HTML. 

“Poshifying" your content means using semantic (X)HTML wherever possible instead of defining structure via other means (for instance, through CSS or WAI-ARIA). Additionally, developers shouldn’t use HTML markup for presentational purposes. For example: 

• Tables should only present data that belongs in tables. Some developers use tables to achieve a certain aesthetic, which can cause accessibility issues.
• Subheading tags shouldn’t be used for their visual appearance alone. 
• Class and id names shouldn’t describe visual presentation, but should focus on function. For instance, <button class=”submit-button"> would be functional, while <button class=”red-button"> would be presentational.

When developers write POSH content — and validate it for compliance against the World Wide Web Consortium (W3C) standards — websites are more accessible (and in many cases, easier to maintain). 

And while “semantic HTML" is a perfectly good descriptor, the “POSH" acronym helps web designers maintain the right mindset. After all, “poshing" a website sounds much more fun than “adding semantic HTML to a website to identify structure.”

Since ARIA is built for assistive technologies, why not use it? 

Plain HTML can provide semantics for most websites, but it’s not the only tool available. WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) provides semantic definitions for interactive or dynamic content, and most assistive technologies support ARIA.

However, the World Wide Web Consortium’s first rule of ARIA is fairly straightforward:

“If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.”

Some older screen readers might not correctly identify certain ARIA roles. Semantic HTML5 is widely supported by every web browser and all assistive technologies. Since the purpose of accessibility is to make content useful for the widest possible audience, POSH is always preferable to ARIA. 

Likewise, microdata and Microformats can nest semantics within existing content, and in certain situations, these extensions can improve accessibility — but not always. By keeping your content as simple and clean as possible, you’ll avoid many common accessibility barriers.

Related: 4 Questions to Ask Before Using ARIA

HTML is (relatively) easy to write and validate

There’s another reason to stick with semantic HTML5: In most cases, a simpler approach will make developers' lives much easier. Every web developer has experience with HTML, which makes troubleshooting fairly straightforward. 

If you don’t have experience with assistive technologies, you might not find certain issues with your WAI-ARIA markup. In some cases, those issues are severe: WAI-ARIA can prevent users from browsing naturally or prevent people from regaining control of their browsers. 

This isn’t to say that WAI-ARIA is useless, or that CSS and Microformats don’t play a role in accessibility. After all, if native HTML could do everything, we wouldn’t need anything else. 

But when developers adopt the POSH mindset, they’re in a great position to create content that functions as intended. Poshified websites are more likely to meet the requirements of the Web Content Accessibility Guidelines (WCAG), the consensus international standards for accessibility. 

Using Semantic HTML to Design Better Content

Here are a few ways to start creating POSH content: 

• Understand the purpose of semantic elements before using them. Our article “Leveraging HTML for Web Accessibility" provides some examples and tips.
• Pay special attention to subheadings, lists, and tables. Make sure you’re using the right semantic element for the job — not because you want the content to look a certain way.
• Before using WAI-ARIA, make sure you really need it. Be prepared to audit your ARIA markup manually; don’t rely on automated validators alone.
• Make sure your structural HTML is consistent across your entire website. 

We recommend reviewing the Microformats POSH home page, a wiki with articles, checklists, and other resources. For additional guidance, contact the Bureau of Internet Accessibility or read our free Ultimate Guide to Web Accessibility.