Accessible Coding for Developers: Semantic HTML, ARIA, and Beyond

Here’s a hard truth — most code works, but not all code is accessible.

If your markup doesn’t use headings properly, your JavaScript traps focus, or your CSS overrides user preferences, you’re unintentionally building accessibility barriers. And with more developers being held accountable to accessible coding standards, “functioning” is no longer good enough. 

Building accessibly from the start doesn’t just avoid compliance headaches — it saves hours of technical debt and rework. You get cleaner code, fewer bugs, and a smoother development process from sprint to launch. 

That’s where accessible coding comes in—writing clean, semantic, and accessible code that works for everyone, especially users of assistive technology or screen readers. For developers, it’s not just about usability and compliance—it’s about craftsmanship.

Whether you’re refactoring legacy code or building a component library from scratch, this guide will help you integrate accessibility directly into your development workflows—not bolt it on later.

First, a quick refresher on web accessibility.

What is Web Accessibility?

Web accessibility ensures digital content can be perceived, operated, and understood by people with disabilities. That includes users with visual, auditory, mobility, or cognitive differences who may rely on tools like screen readers or keyboard navigation. Accessible coding removes accessibility barriers by structuring content semantically, providing meaningful labels, enabling keyboard access, and respecting user preferences. 

For example, using a <button> element instead of a <div> with click handlers ensures the element is announced correctly by screen readers and can be triggered with a keyboard. 

Understanding Assistive Technology and Why it Matters for Developers

Assistive technology refers to tools that help users interact with digital content in non-traditional ways, such as:

• Screen readers (e.g., JAWS, NVDA, VoiceOver) that read content aloud

• Voice input systems like Dragon or built-in OS voice control

• Alternative keyboards and switch devices

• Screen magnification that zooms into content without distortion

These tools don’t “see” your site — they parse your code. ARIA roles, semantic structure, and logical focus order directly affect how users experience your interface. Poor or inaccessible code breaks that experience, regardless of visual design or features.

Blue collage of accessibility and email symbols

How to Write Code that Meets WCAG Criteria

Writing accessible code means more than passing an automated test — it’s about improving the experience for real-world assistive technology users and others with disabilities. The Web Content Accessibility Guidelines (WCAG) 2.1 includes the required standards, but developers need to know how to implement them in code.

The following best practices are focused on structural, responsive, and functional techniques that help you meet key WCAG criteria through solid, maintainable code.

Use Semantic HTML with Native Controls First

This is arguably the most crucial principle around accessible coding, so if you only take one thing with you, make it this: start with semantic HTML. It’s the easiest and most reliable way to create an experience that works across screen readers, keyboards, and other assistive tools.

Semantic elements carry built-in roles, behaviors, and keyboard interactions that AT can rely on. This is the foundation of semantic HTML accessibility. 

Use this:

<button type="submit">Save</button>

Not this:

<div role="button" tabindex="0" onclick="save()">Save</div>

While ARIA can help in certain cases, native HTML elements like <button>, <a>, <form>, and <label> are far more robust, accessible, and easier to maintain. Using native HTML controls ensures compatibility with browsers and AT out of the box.

Bonus tip: Avoid overwriting default element behaviors unless absolutely necessary — doing so can disrupt expected interaction patterns.

Create an Accessible, Responsive Design

Responsive design isn’t just about fitting content on different screen sizes — it’s about ensuring content remains usable and readable for everyone, including those with low vision, motor impairments, and cognitive disabilities.

Poorly implemented responsive code can create barriers like clipped text, broken layouts, or hidden content when users zoom or resize text. This disproportionately affects people who rely on browser zoom, larger font settings, or mobile accessibility features. 

Accessible responsive design means creating layouts that adapt visually and functionally — preserving readability, operability, and structure across devices and user preferences. 

Here are some best practices for creating an accessible responsive design:

• Support text resizing: Use relative units (rem, em) instead of fixed pixels (px) for text and containers. This ensures your content scales correctly when users increase font size via browser settings or OS-level preferences.

• Avoid fixed dimensions: Don’t lock containers with fixed heights or widths. Use min/max widths or let elements grow with content to prevent clipping or overflow when zoomed.

• Flexible, reflowable layouts: Leverage CSS Grid or Flexbox to create layouts that adjust smoothly without horizontal scrolling, in line with WCAG success criterion 1.4.10: Reflow.

• Accessible touch targets: Make interactive elements like buttons or links large enough to tap easily (minimum 44x44px). Ensure spacing between elements to avoid accidental activation, especially for users with motor challenges.

• Avoid hover-only or gesture-dependent features: If a function requires a hover or swipe, ensure it can be triggered with a keyboard or visible control. WCAG doesn’t assume mouse or touch as the default input. 

The bottom line: accessible responsive design helps ensure your content works not just on mobile devices, but across a range of assistive technologies and user settings — making it a core part of coding for accessibility. 

Meet WCAG 2.1 Coding Criteria

WCAG 2.1 includes dozens of success criteria, but some have a direct, daily impact on how to write accessible code. Below are some of the most relevant coding standards to follow when building accessible experiences for assistive technology users. 

1.3.1 Info and Relationships

Structure and relationships must be conveyed through code — not just visually. To achieve this, ensure you:

• Use headings (<h1> - <h6>) to define page hierarchy

• Associate form fields with <label for> or aria-labelledby

• Use semantic containers like <section>, <nav>, and <main> for page regions

Assistive tech relies on each of these cues to help users understand how content is organized and how elements relate to each other. 

2.4.4 Link Purpose (In Context)

Links must clearly describe their purpose, even when taken out of context. Ensure each of your links includes descriptive text like “download accessibility guide” rather than “click here.” For icon-only links, add aria-label or visually hidden text to explain their function.

Doing so enables users who navigate by links — such as screen reader or voice control users — often skim a list of links and need meaningful labels to decide where to go.

4.1.2 Name, Role, Value

Interactive elements must expose their accessible name, role, and state through code under WCAG 4.1.2. To do this, ensure you:

• Use native HTML controls like <button> and <input> when possible

• Add ARIA roles and labels only when needed, and ensure they’re updated dynamically

• Keep aria-checked, aria-expanded, etc. in sync with your actual UI state

Using elements this way ensures screen readers and other assistive tech understand what something is, what it does, and what state it’s in.

1.1.1 Non-Text Content

All non-text elements must have a text alternative (or alt text) that serves the same purpose. More simply, non-text elements like images or graphs must include a written description of that image. Additionally, decorative elements should be marked with alt=”” or aria-hidden-”true” and icon buttons should be labeled using aria-label or aria-labelledby. For users who can’t see images or visual UI, these elements ensure they understand what those elements do or represent.

2.1.1 Keyboard

All functionality must be navigable and usable by a keyboard alone — no mouse or touch required. Below are a few ways to code elements to be keyboard navigable:

• Use keyboard-accessible elements like <button> or <a href>

• Avoid mouse-only events like onClick without onKeyDown

• Make sure modal dialogs, drop-downs, and menus can be fully operated by tabbing and the arrow keys

2.4.3 Focus Order

Like​​ the keyboard alone criteria, content must also be navigated in a logical and predictable order using the keyboard. This includes:

• Ensuring DOM order matches the visual reading order

• Avoiding disrupting focus with JavaScript unless it’s intentional and helpful (e.g., moving focus into a modal)

• Being cautious when using ‘tabindex’ unless needed

• Avoiding values above 0

Each of these elements ensures users can experience content in the intended sequence, especially those navigating without a visual display.

3.3.1 Error Identification and 3.3.2 Labels or Instructions

Users must be clearly informed when they make a mistake and be given clear, accurate steps on how to fix it. WCAG 3.3.1 and 3.3.2 include recommendations on how to develop this, including:

• Pair each form field with a visible label

• Show error messages near the field and announce them using aria-live or inline alerts

• Avoid relying on red borders or icons alone and using text explanations instead

Accessible error handling helps all users — especially those cognitive or visual disabilities — complete forms confidently and resolve errors on their own.

A screen reader being used to test a website for alternative text

Testing Accessible Code

Writing accessible code is only half the job — you need to test it to ensure your users, including those with disabilities, can actually interact with it. There’s a myriad of ways you can test your code for accessibility; however, we recommend taking a hybrid approach, combining automated tools with expert testing for a more complete picture. 

Expert Testing and Audits: What You Can’t Skip

Expert testing and audits involve accessibility experts and, ideally, members of the disability community interacting with your code to identify accessibility issues. The approach typically involves simulating real-world user interactions and catching issues that automation might miss. Some of the most common manual testing approaches include:

Keyboard-Only Testing

• Navigate your site using only tab, shift + tab, enter, and arrow keys.

• Check if interactive elements (buttons, links, modals, drop-downs) are reachable and operable.

• Look for keyboard traps, missing focus indicators, and broken tab order.

Screen Reader Testing

• Use tools like NVDA (Windows), VoiceOver (Mac), or TalkBack (Android) to experience your site as a blind or low-vision user would. 

• Check for clear labeling, proper reading order, and announcement on dynamic content.

Tip: Consider starting with NVDA + Firefox or VoiceOver + Safari for the most consistent screen reader results. 

Testing Accessible Code

Writing accessible code is only half the job — you need to test it to ensure your users, including those with disabilities, can actually interact with it. To test website accessibility effectively, we recommend combining automated and expert testing. Each approach catches different issues and gives you a more in-depth understanding of how accessible and usable your content is.

Here’s how we recommend testing your code:

1. Automated Accessibility Testing

Automated testing tools give you a great starting point for enhancing accessibility and meeting compliance requirements. These tools use software to scan your content and identify common accessibility issues, including missing alt text, poor color contrast, unlabeled form fields, and improper ARIA usage. 

For example, AudioEye’s Web Accessibility Checker automatically scans your content for 32 WCAG violations (more than any tool on the market), giving you a clear understanding of how accessible your content is. Our Accessibility Platform then applies Automated Fixes for these issues, streamlining your path to accessibility. 

However, automation can’t catch all accessibility issues, which is where expert testing comes in.

2. Expert Testing

Expert testing is essential as it surfaces issues that automated tools can’t catch — like confusing focus behavior, unclear link text, or unexpected screen reader output. Automation is a great starting point, but we recommend doing the following tests on your own and with users with disabilities to enhance accessibility further.

Keyboard Testing

Start by putting the mouse aside and using only the keyboard, and test the following actions:

• Use ‘Tab’ and ‘Shift + Tab’ to move forward and backward through focusable elements.

• Use ‘Enter’ or ‘Space’ to activate buttons, links, and toggles.

• Use the arrow keys to interact with components like menus, sliders, and other elements.

As you’re testing keyboard commands, make sure all interactive elements are reachable, the focus order follows the visual layout, and the focus indicator is always visible and never gets lost. You’ll also want to ensure there are no keyboard traps (when users are unable to move focus away from a particular element) and that focus returns when elements are closed. 

Screen Reader Testing

Because a large portion of users with disabilities rely on screen readers to navigate digital content, you’ll want to ensure your content works well with these devices. Here’s how to confirm your code works with real assistive tech:

• Use NVDA + Firefox (Windows) to test desktop content.

• Use VoiceOver + Safari (Mac/iOS) to test built-in commands for Apple users.

• Use TalkBack (Android) to test mobile content. 

As you’re doing screen reader testing, pay attention to the following:

• Does the screen reader announce labels, roles, and states correctly?

• Is the reading order logical?

• Are landmarks (like <nav> or <main>) discoverable?

• Do dynamic updates (like form errors or status changes) get announced?

• Are links and buttons clear without surrounding context?

It’s highly recommended to involve users with disabilities in screen reader and keyboard testing, as they can find accessibility issues that may not be obvious at first glance. Any content that is confusing or difficult to navigate or confusing should be improved to ensure it doesn’t negatively affect users.

3. Test Early, Test Often

One thing to remember: accessibility testing isn’t a one-time task — it’s a habit. Think about it this way: whenever you update content, add a new web page, write a new blog post, or post any new content, you’re potentially introducing new accessibility issues. Without regular accessibility testing, you increase the risk of those issues impacting your users and increasing your chances of legal consequences (e.g., fines and penalties, demand letters, and even lawsuits). 

To avoid this, accessibility should be built directly into your workflows. Here’s how:

• Run regular accessibility scans during development (before code review).

• Add keyboard and screen reader testing to QA checklists.

• Set accessibility as a quality gate for production. 

• Incorporate testing tools — like AudioEye’s Web Accessibility Checker — into your CI/CD pipeline or browser workflow for ongoing testing and monitoring.

The bottom line: The earlier you catch issues, the easier they are to fix — and the better experience you’ll create for everyone.

Someone using a screen reader as assistive technology next to their computer keyboard.

Build Better, More Accessible Code with AudioEye

Making your code accessible isn’t about just checking boxes — it’s about improving the experience for everyone. By making your code more accessible (and compliant with digital accessibility laws), you:

• Create a better user experience for people with and without disabilities.

• Boost your SEO rankings thanks to cleaner, semantic, well-structured content.

• Lower your legal risk by aligning with WCAG and ADA requirements.

Even small changes — like using a semantic <button> or ensuring proper keyboard focus — can have a massive impact on real users who rely on assistive technology to navigate the web. And when accessibility is baked into your development process, it scales naturally across projects. 

If you’re ready to take the next step in building accessibility into your workflow, there’s AudioEye. From our free Web Accessibility Checker to our Expert Audits, AudioEye enables you to detect and fix issues and achieve industry-leading compliance with accessibility standards. Plus, with AudioEye’s Developer Tools, you can bring accessibility testing directly into your development workflows and proactively address issues early, minimizing the need for costly retroactive fixes. 

Want to go even further? AudioEyeQ offers a free, self-paced, expert-led accessible coding course. In it, you’ll learn accessibility requirements for common UI elements, basic testing routines, and problem-solving resources.

Get started by signing up for AudioEye’s Accessible Coding course or getting a free accessibility scan.

To see AudioEye in action, schedule a demo.