Blog

Sensible HTML5 Accessibility Best Practices

5 seconds ago
0 Comments

We know it’s hard. When you’re coding away with all the new fancy frameworks that are out there today. Keeping your bundle size low, ensuring fast load times and having the time to worry about accessibility (a11y).

It can be hard but trust me, creating an accessible HTML5 document doesn’t have to be a pain in the ass list of government standards. All we need to do is create good usable HTML5 documents that people will consume. Whether its from their computer, phone (probably a crappy one while riding a bus), screen reader or just plain ol keyboard navigation.

HTML5 has come a long way to help us out. Below I will go over some useful tips and tricks that I think you should use everyday when coding.

1. Ditch the “Div Soup” and Embrace Semantic HTML

Before you reach for another generic <div> or <span>, take a breath. HTML5 gave us a rich toolbox of semantic tags—like <header>, <nav>, <main>, <article>, <section>, <aside>, and <footer>—for a reason.

When a screen reader hits a page built with semantics, it can generate a “document outline” or list of landmarks. This allows a user to jump straight to <main> and skip your giant 40-link header without breaking a sweat. If your entire layout consists of nested <div> containers, screen readers just see a wall of noise.

Rule of thumb: If a tag exists that describes the role of the content, use it. Save <div> strictly for CSS wrappers and styling hooks.

2. Don’t Reinvent the Wheel (Use Native Interactive Elements)

We’ve all seen it:

<!-- Please don't do this -->
<div class="btn" onclick="submitForm()">Submit</div>

Sure, with enough CSS you can make a <div> look like a polished button. But out of the box, it lacks keyboard focus, cannot be activated with the Enter or Space keys, and announces itself to assistive tech as plain text. To fix that, you’d have to manually add tabindex="0", role="button", and custom keyboard event listeners.

Why do all that work when the humble <button> tag does it natively for free? Native elements like <button>, <input>, <select>, and <a> come loaded with built-in accessibility, standard focus states, and browser-level keyboard ergonomics.

3. Treat Alt Text as Context, Not Decoration

The alt attribute on an <img> tag is probably the oldest accessibility feature on the web, yet it remains one of the most misused.

  • If an image conveys information: Describe the meaning, not just visual trivia. For a chart showing revenue growth, write alt="Bar chart showing Q3 revenue up 25%" instead of alt="graph".
  • If an image is purely decorative: Use an empty alt tag (alt=""). Don’t omit the attribute entirely! Leaving it off makes some screen readers read out the raw filename (e.g., alt="IMG_20261008_hero_final_v2.png"), which is a miserable user experience.

4. Forms: Connect Your Labels and Controls

Forms are where transactions happen, whether signing up for a newsletter or checking out a shopping cart. If your forms aren’t accessible, you are actively turning users away.

Always tie labels directly to inputs using the for attribute matching the input’s id:

<label for="user-email">Email Address</label>
<input type="email" id="user-email" name="email" required autocomplete="email">

Clicking the label focuses the input (which is great for mobile usability), and screen readers will announce the input’s purpose the moment it gains focus. Also, lean into HTML5’s input types (type="email", type="tel", type="url") and built-in attributes like required and autocomplete. They give mobile users the right keyboard layout and give assistive software clear expectations about input validation.

5. Mind the Heading Hierarchy (<h1> through <h6>)

Headings are the structural backbone of your content. People who use screen readers frequently scan pages by skipping through headings, treating them like a table of contents.

  • Stick to one <h1> per page representing the main topic.
  • Don’t skip levels just to match a design size (e.g., jumping from <h2> directly to <h4>). If you need smaller text, change the font size in CSS, not the heading level in HTML.

6. Protect Keyboard Navigation & Focus Rings

Unplug your mouse for fifteen minutes and try navigating your site using only the Tab, Shift + Tab, and Enter keys.

Can you tell which element currently has focus? If not, you might have fallen victim to the infamous:

/* Avoid stripping focus without a replacement */
*:focus {
  outline: none;
}

Never strip away focus outlines without replacing them with a clear, custom styling. If users can’t see where their cursor is, they can’t navigate. Additionally, make sure your tab order mirrors the logical visual order of the page.

7. ARIA: Use It as a Pepper Shaker, Not a Soup Base

ARIA (Accessible Rich Internet Applications) attributes are powerful lifesavers when building custom, complex UI widgets like accordions, tabs, and modals.

However, the First Rule of ARIA is: If you can use a native HTML element or attribute with the semantics and behavior you need, do that instead of repurposing an element and adding ARIA.

Bad ARIA is often worse than no ARIA at all because it actively lies to assistive technology about what an element is or does. Use native HTML first; add aria-expanded, aria-live, or aria-labelledby only when HTML doesn’t have a built-in way to express the interaction.

Helpful Reference Links & Further Reading

If you’re looking to dive deeper and test your work, keep these go-to resources bookmarked:

The Takeaway

Accessibility isn’t an “all-or-nothing” mountain you have to climb overnight. Start by writing clean, semantic HTML5, ensuring your buttons are actual buttons, labeling your inputs, and checking keyboard navigation. Those simple habits alone will make your site friendlier and more usable for just about everyone on the internet.

Tags:
Shares:

Leave a Reply