web developers Archives /Tag

Accessible WooCommerce Themes: Top Picks & What to Look For
When you pick a WooCommerce theme, you are not just choosing a layout. You are choosing how easy your store is to navigate, how clearly information is announced, and how much work it will take to keep things compliant over time. If you’re comparing accessible WooCommerce themes, the real question is not “Which one looks nicest?” but “Which one gives my customers the smoothest, most predictable path from homepage to checkout?”

Many teams choose under pressure: a redesign, a migration, or a branding push. It’s tempting to grab the first nice demo and plan to fix accessibility later. In practice, this creates more rework, more risk, and more frustration for users who rely on assistive technology.

You can quickly bring accessibility into your theme decision. Add structure, make targeted checks, and know your priorities to move forward with confidence.

Why Your Theme Choice Shapes More Than Just Design

A WooCommerce theme controls more than colors and fonts. It ships with its own templates, layout decisions, and code patterns. That means it shapes:
- How screen readers move through your pages
- What paths do keyboard users take to reach menus, filters, and checkout?
- How your store behaves on small screens and at high zoom
- How easy it is to keep things maintainable as you grow
Starting from one of the stronger accessible WooCommerce themes puts you ahead in several ways. You spend less time fixing basic issues, see fewer regressions when plugins update, and send a clear signal to customers that your store is built for them—not just for aesthetics. It can also reduce legal risk, because you are closer to what laws and guidelines expect when they reference the Web Content Accessibility Guidelines (WCAG) and the Americans with Disabilities Act (ADA).

Accessibility is not only an ethical choice; it is a business one. Sites that are easier to use convert better, generate fewer support tickets, and are less likely to be named in a lawsuit. For many teams, “accessible by default” is simply a smarter way to protect brand, revenue, and reputation simultaneously.

What “Accessible” Really Means in Practice

Guidelines like WCAG exist to turn a big idea—“everyone should be able to use the web”—into concrete checks. Over the years, WCAG has evolved (2.0, 2.1, 2.2), and most legal frameworks point to at least Level AA as the baseline. Level AAA is more stringent and often not practical for full ecommerce flows, so most teams aim for AA and build from there.

You do not have to memorize every success criterion, but it helps to know what a theme should support. Think of it through four simple lenses:
- Perceivable: Text has strong contrast, scales well, and is not buried in images. Important images have alt text. Links are descriptive rather than repeating “Learn more” 10 times, so people know where they are going.
- Operable: Menus, filters, dialogs, sliders, and forms work with a keyboard alone. Focus is always visible. Nothing traps people in a pop-up, mini-cart, or off-screen menu. Moving content can be paused or controlled instead of constantly sliding past.
- Understandable: Labels and instructions are clear. Errors explain what went wrong and how to fix it. Navigation and headings follow predictable patterns from page to page, so shoppers do not have to constantly re-learn how your site works.
- Robust: The HTML uses proper headings, landmarks, and controls. ARIA is applied thoughtfully, not sprinkled everywhere. The store works with screen readers, zoom, and narrow viewports, and does not fall apart when the browser or assistive tech changes.
If a theme gives you a solid start on all four, you are in a much better place than a design-first theme that just happens to “look clean.”

Common Problems You’ll See When You Test Themes

One thing that often surprises teams: many themes that market themselves as “accessible” still have rough edges. Even themes promoted as accessible WooCommerce themes can struggle with basics when you look beyond the promo page.

The most frequent trouble spots include:
- Weak or missing keyboard navigation
  No skip links, no focus outline, menus that cannot be opened with a keyboard, or dropdowns that open on hover only. Sometimes you can tab into a menu but never back out cleanly.
- Code issues behind the scenes
  Missing labels, misused landmarks, custom controls built from generic <div> elements, or error messages that never get announced. Cart updates might happen visually but remain invisible to screen readers.
- Design choices that work visually, but not accessibly
  Low-contrast buttons on hero images, very small text, or links that are only distinguished by color. On a large monitor, these might look elegant; on a smaller laptop or with aging eyesight, they become a barrier.
- E-commerce-specific gaps
  Product ratings hidden from assistive tech, price filters that only work with a mouse, or variation selectors that cannot be reached with the keyboard. Sometimes a “quick view” or slide-out cart steals focus and never gives it back.
Seeing one of these issues is not a reason to abandon a theme right away. Seeing many of them together usually indicates that your time is better spent on a different starting point.

WooCommerce Themes With Better Built-In Accessibility

No theme is perfect out of the box, but some give you a better baseline than others. Below are themes that often get teams closer than most other accessible WooCommerce themes right out of the box. You should still test any version you plan to use, along with your plugin stack, but these tend to show stronger intent.

Storefront

Built by the WooCommerce team, Storefront is deliberately simple and stable. It includes skip links, workable keyboard navigation, and a product-focused layout. You will likely want to layer on your own design system, but the structural choices are solid, which is exactly what you want from a base theme.

Neve

Neve balances flexibility with fairly clean markup. It usually includes proper landmarks, readable typography, and skip-to-content links. When you change colors or layouts, re-run contrast checks and re-test menus and headers—especially any mega menus or sticky headers you introduce.

Responsive

Responsive tends to perform well with responsive layouts, spacing, and contrast-friendly presets. Skip links and keyboard navigation are present, though imported template kits should always be checked individually. Some ready-made layouts might be less robust than the core theme, so treat them as starting points, not guaranteed safe patterns.

OceanWP

Popular for performance and options, OceanWP supports skip links and keyboard-friendly dropdowns. Focus on visibility and contrast, as they can vary depending on configuration. Harden them early in your build and keep a close eye on badges, secondary buttons, and sale labels.

Eimear and Monument Valley

Eimear and Monument Valley are known for prioritizing accessibility in their design. Multiple skip links, structured navigation, and responsive templates are common strengths. Dynamic pieces like filters, accordions, or cart notices still need real-world testing, but you are starting from a posture that takes accessibility more seriously than most.

The point of a shortlist is not to promise perfection; it is to avoid starting from a theme that fights you at every turn.

How to Vet a Theme’s Accessibility Quickly

Once you have a few candidates, you can move beyond marketing pages and see how each one behaves in practice. Use this checklist when you are evaluating accessible WooCommerce themes in the wild:

Do a Full Keyboard Tour

From the browser’s address bar, tab through the header, navigation, product grid, product detail page, cart, and checkout. Make sure you can see focus at every step and that ESC closes any open menu or modal. If you lose track of focus or end up “stuck” in an element, note it as a real risk.

Check Headings and Landmarks

Look for one main heading per page and a logical order beneath it. Confirm that regions like navigation, main content, and footer are clearly defined and not duplicated in confusing ways. This is what screen reader users rely on to jump around the page.

Test Forms and Messages

Add something to the cart. Trigger a form error. Apply a coupon. Ask: Is the feedback clear both visually and for screen readers? Does anything important happen silently? Error messages that only appear as red text, with no programmatic link to the field, are a common pattern to flag.

Zoom and Shrink

View the site at 200% zoom and at a narrow mobile width. Nothing important should overlap, spill off-screen, or become unreachable. Pay special attention to sticky headers, floating chat widgets, and fixed promos that can hide content when zoomed.

You can supplement this with quick automated checks (for example, running a browser extension or audit tool against the demo), but those should confirm your observations—not replace hands-on testing. If a theme passes this quick pass with only small issues, it is usually worth deeper evaluation.

Fixing Gaps When Your Theme Is “Almost There”

In most cases, you will end up choosing a theme that is “good, but not perfect.” That is normal. Once you have picked one of the more accessible WooCommerce themes, you will almost always still find gaps during real testing.

A practical way to tighten things up:
- Start with built-in controls.
  Use the theme’s and Site Editor’s options for color, typography, and spacing to fix contrast and legibility problems. This is usually the fastest way to bring large pieces of the site into alignment.
- Strengthen focus
  Add CSS to make focus rings thick, high-contrast, and consistent across all interactive elements. If you can see it clearly from a distance, a customer is far less likely to get lost.
- Swap custom elements for native ones.
  Replace “clickable divs” with actual buttons or links. Use real form fields for filters and variations. Native elements carry a lot of built-in accessibility that you do not have to re-create from scratch.
- Improve complex widgets
  For menus, tabs, accordions, and sliders, follow established patterns and then test with a keyboard and a screen reader. Focus moves, aria-expanded states, and visible labels all need to line up.
- Keep your plugin list lean.
  Every extra plugin is another chance to introduce inaccessible markup or conflicting scripts. Audit your plugin stack and remove anything you are not actively using.
When you identify gaps, prioritize fixes based on where money moves: product lists, product details, cart, and checkout first. Document the patterns you fix and treat them as reusable building blocks. That prevents the same problems from creeping back in later.

How to Maintain Accessibility After Launch

Even a well-built store can drift out of alignment over time. New campaigns, landing pages, and plugins all add risk. Treat accessible WooCommerce themes as a foundation, not a finish line.

Simple habits help:
- Run quick keyboard checks after theme or plugin updates.
- Keep short, clear guidelines for alt text, link text, and headings
- Schedule light accessibility spot checks before major campaigns
- Offer small refreshers for anyone who creates or edits content.
- Add a short accessibility checklist to your release process so changes get a quick sanity check before going live.
These steps do not require a full rebuild, but they do keep your store usable and reduce surprises.

Your Theme Is the Start—Accessibility Is Ongoing

Choosing a WooCommerce theme is one of the earliest—and most important—accessibility decisions you make. The right foundation can support better customer experiences, smoother growth, and lower risk. The wrong one can lock you into constant workarounds.

You do not have to solve every detail up front, but you can put your store on a stronger path by choosing a theme with accessibility in mind, testing it as a real customer would, and making small, steady improvements as you go.

If you would like a second set of expert eyes on your shortlist—or a clear picture of how your current theme holds up—schedule an ADA briefing with 216digital. We will review real storefront flows, call out the highest-impact fixes, and map out a practical path toward WCAG-aligned accessibility and better conversions.
Greg McNeil

November 25, 2025

Legal Compliance, Web Accessibility Remediation

Web Accessibility, web developers, web development, Website Accessibility, WooCommerce, WooCommerce themes, WordPress
Accessible 404 Page: Turn Errors Into Wins

You click a link with a clear goal in mind and, instead of the content you expect, you hit a 404 page. For a second or two, you wonder whether you mistyped the URL, the site is broken, or if the content has disappeared. In that short pause, trust gets shaky. This is also where web accessibility and UX come together in a very real way: either the page leaves people stuck, or it gently helps them move forward.

That “not found” state is often seen as a throwaway screen, something the server shows when nothing else fits. With a bit of planning, this moment can be a calm, honest checkpoint. It explains what happened, offers clear next steps, and reassures people they’re still in the right place.

In the sections ahead, we will unpack what a 404 really is, how to frame it as a recovery rather than a failure, which inclusive design patterns matter most, and how architecture and analytics can support that work. By building this foundation, we can see how each layer—technical, experiential, and strategic—interacts to create an error response that turns an obstacle into a small signal of care that feels intentional, helpful, and human.

What a 404 Really Is — and Why It Happens

At the technical level, a 404 response is straightforward: the server looked at the requested URL and could not find a matching resource. That might be because content moved, a slug changed during a redesign, a redirect rule was missed, or the link was simply typed incorrectly.

The reality on most teams is a little more complicated. Content is added and removed over the years. Campaign landing pages go live for a season and then vanish. Migrations reshuffle URL patterns. Old PDFs and email templates keep sending people to paths that no longer exist. Over time, these small changes add up to a steady stream of “not found” visits.

Each of these visits is more than a missing document. It is a broken step in a user journey. Someone who trusted your link now has to decide whether to keep going, try again, or leave. Search engines see this pattern too: a cluster of broken internal links or confusing responses can send negative signals over time.

Treating that view as a recovery screen changes how you design. Instead of thinking, “The request failed,” you start asking, “How do we help this person take a meaningful next step?” This shift leads directly into the principles that guide effective 404 experiences.

Principles Before Pixels: A High-Performing 404 page Experience

Before you sketch a layout or write a clever line, it helps to agree on a few guiding ideas.

1. Accessibility is Not Optional

If parts of your experience are already hard to use, a broken link makes things worse. Folding the 404 template into your larger accessibility strategy ensures that the same care you give your main flows also applies in edge cases.

2. Clarity First, Personality Second

A bit of humor can soften the moment, but only after the page explains what went wrong and what the user can do now. Plain language always wins in high-friction states.

3.Stay On-brand

The 404 view should reuse the same typography, color system, and navigation patterns as the rest of the site. That continuity tells people they are still inside a trusted environment, even though something went wrong.

4. Focus On Recovery, Not Apology

A short, human message is important, but the screen’s real job is to provide useful paths forward and to gather enough data that you can keep improving the template over time.

Designing with these principles in mind sets you up to turn the 404 view into a small but meaningful part of the overall experience instead of a forgotten corner. Now, let’s look at the specific accessibility must-haves that support such inclusive error states.

Accessibility Must-Haves for an Accessible 404 page

When someone lands on an error view, they are already a little off-balance. The job of an accessible 404 page is simple: make it clear what happened, make it easy to recover, and make sure that experience works for more than one way of browsing. This is where UX and web accessibility meet in a very practical way.

A Clear Statement of What Happened

Start with a direct, plain-language heading that names the situation: “Page not found” or “We can’t find that page.” The short text that follows should explain, in one or two sentences, what that means and what the person can do next. No jargon. No blame. Just context and next steps.

A Layout That Still Feels Like “Your” Site

Even in an error state, users should feel grounded. Keep the same basic frame as the rest of your site—header, footer, typography, and overall rhythm. Familiar structure helps people using assistive tech or high zoom recognise that they have not been dropped somewhere unsafe or unrelated.

Recovery Paths That Are Easy to Spot and Use

The main routes off the page—a primary button, a search field, a small set of helpful links—should be visible without hunting and usable for people who navigate in different ways. That means clear labels, sensible tab order, and enough spacing that links and buttons are easy to pick out at a glance.

Text and Visuals That Hold Up Under Strain

Treat this template as a first-class reading experience. Body copy should be large enough, well spaced, and set against backgrounds with solid contrast. Any illustrations should support the message, not compete with it. If the visuals are just there for tone, they should be easy to ignore for anyone focused on getting back on track.

A Moment That Stays Stable, Not Jumpy

When someone reaches your 404 page, they need a beat to understand where they are and decide what to do. Avoid sudden auto-redirects or timed jumps away from the screen. A stable state is kinder to screen-reader users, keyboard users, and anyone who simply reads at a different pace—and it aligns with the spirit of web accessibility as a whole.

Page Anatomy: What to Include on Your 404 page

Once the foundation is set, you can start thinking about the screen’s anatomy.

Start with a headline and a brief empathy line. Something like, “We can’t find that page. Let’s get you back to something useful,” is honest and calm. It acknowledges the break without blaming the user or hiding behind technical jargon.

Next, add primary recovery paths. Place a clear button to your home page or a key hub to make resetting easy. A search field gives control to people who know what they seek. Short lists of curated links—popular sections, current campaigns, most-read articles—offer quick options if visitors want to explore.

Consider including a small, accessible feedback mechanism, such as a link that says, “Tell us if this link is broken.” When wired into your issue-tracking or analytics layer, this can reveal patterns that automation alone might miss.

Visually, keep the layout simple and open. Maintain your main header and footer so orientation is never in doubt. If the user came from a specific area, such as “/blog/” or “/support/,” you can surface related links to those sections to respect their original intent. In every case, ask whether the design makes it obvious what to do next.

Under the Hood: Technical Details That Support the Experience

The best copy and layout will fall short if the underlying implementation is weak. Your 404 page should be backed by correct HTTP status codes so search engines and monitoring tools know what is happening. For permanently removed content, a 410 status may make more sense than a 404, but the visual template can remain the same.

In client-side apps, routing logic needs extra care. When a user visits an unknown path, your router should render the error template and, when possible, coordinate with the server so that crawlers also receive the correct signal. Focus management, skip links, and semantic markup should be tested together so that the experience holds up for people using assistive technology. These technical details are small, but they add up to better web accessibility in the moments when users most need guidance.

Caching and performance matter here as well. Configure your CDN so error responses are cached sensibly, and ensure the template itself loads quickly with minimal heavy scripting. People are already dealing with a disruption; they should not have to wait for the recovery tools to appear.

Do not forget metadata. A clear title like “404 – Page not found” and well-structured meta tags make the state easier to recognise in analytics dashboards and open tabs. If your site serves multiple languages or regions, localise the copy and the key links so the experience feels considered, not generic.

Analytics, Monitoring, and Continuous Cleanup

A recovery view is not “done” once it ships. Logging and analytics should tell you how often people hit it, which paths send them there, and what they do next. Over time, this reveals where your architecture is working well and where it is quietly letting visitors down.

Simple dashboards can highlight the most common missing URLs, the internal pages that generate the most errors, and the CTAs that lead to successful recovery versus quick exits. You can even test variations of copy or link groupings to see which version helps more journeys continue.

Seen this way, the 404 page becomes a kind of listening post. It shows you where expectations and reality do not match—and gives you a place to respond with better structure, clearer navigation, and stronger web accessibility patterns.

Governance: Building Habits That Reduce Future 404s

Preventing needless errors is a shared responsibility. When content owners remove or rename pages, they should follow a simple checklist: update internal links, add redirects where appropriate, and document what has changed. Marketing teams should plan end-of-life steps for campaign URLs instead of letting them quietly break. Developers can integrate link checking into CI to catch internal broken links before launch.

For design and UX teams, the error view should live inside the design system as a standard template with clear accessibility criteria. During QA, it should receive the same level of attention as a key landing page: keyboard-only walkthroughs, high-zoom checks, screen-reader tests, and mobile scenarios. These habits turn one fragile corner of the site into a dependable part of your service.

Education is the final layer. When teams see the 404 state not as a failure but as a recoverable moment, they are more likely to invest in it. When they understand that good handling here is part of web accessibility, not just “nice to have” polish, they will keep it in scope during redesigns and migrations instead of leaving it behind.

Not All Wrong Turns Are Dead Ends

A missing resource will always create a small moment of friction, but what happens next is up to you. Treated with care, a well-designed 404 page becomes proof of how you handle the unexpected: calmly, clearly, and with respect for every visitor’s needs.

When people land on a thoughtful, well-structured error template, they stay oriented, feel supported, and are more likely to continue their journey with your brand. You protect trust, learn from the patterns that brought them there, and strengthen both your UX and your web accessibility at the same time.

If you would like a fresh perspective on how your own error and recovery states are working for users, the team at 216digital would be glad to help. An ADA briefing can surface quick wins, highlight deeper structural opportunities, and give your teams practical, actionable next steps.

The next time someone takes a wrong turn on your site, they will not just see a dead end. They will see a clear map forward—and a quiet signal that someone on the other side of the screen has their back.

Greg McNeil

November 21, 2025

How-to Guides

404 page, How-to, Web Accessibility, web developers, web development, Website Accessibility
How Content Order Impacts Accessibility and User Experience
If you build modern interfaces, you probably lean on Flexbox, Grid, and positioning every day. With a few lines of CSS, you can rearrange entire sections, change layouts at different breakpoints, and keep one codebase working across phones, laptops, and large screens.

The downside is easier to miss: the more we shuffle things visually, the more likely it is that the visual order drifts from the actual HTML order and undermines accessibility. When that happens, people using a keyboard or screen reader can have a very different experience from what the design suggests. Focus jumps in ways they don’t expect. Announcements feel out of place. It becomes harder to stay oriented on the page.

For users who rely on assistive tech, it can feel disorienting when the page organization changes unexpectedly. “Next” may not always mean “next,” and navigating the page can require more effort to stay oriented.

This isn’t only a UX problem. It ties directly to WCAG 1.3.2 Meaningful Sequence and 2.4.3 Focus Order, which both expect content and focus to follow a logical, predictable path. That same alignment supports accessibility and reduces risk from a legal perspective.

In the rest of this article, we’ll look at how order breaks, where they tend to happen, and practical ways to design, test, and fix layouts so they stay flexible without becoming unpredictable.

Why Content Order Matters More Than It Looks

How Assistive Technologies See Your Layout and Accessibility

Screen readers don’t “see” layout. They move through the DOM in source order, using headings, landmarks, lists, and controls to understand how the page is structured. That’s the experience for someone listening linearly or jumping by element type.

Keyboard users follow the same underlying map. Each press of Tab moves through links, buttons, and form fields in DOM order, unless you’ve changed it with tabindex or custom scripting.

When the visual layout suggests one order and the DOM provides another, people feel things like:
- Focus jumping to unexpected areas.
- Content is being announced without a clear context.
- A mental model of the page that never really settles
Once trust is lost, every interaction requires more effort.

WCAG’s View: Meaningful Sequence, Focus Order, and Accessibility

Two Web Content Accessibility Guidelines (WCAG) criteria are especially relevant:
- WCAG 1.3.2 Meaningful Sequence requires at least one programmatically determinable reading order that preserves meaning. If someone moves through the content in DOM order, it still needs to make sense.
- WCAG 2.4.3 Focus Order requires that focusable elements receive focus in an order that preserves meaning and operability. Keyboard users should not feel like focus is bouncing randomly around the page.
These expectations sit near the center of a solid accessibility approach.WCAG does not forbid visual rearrangement. It becomes a problem when the rearrangement changes how users understand the page or makes it harder to complete tasks. There can be more than one acceptable logical order, but at least one needs to be consistent and predictable.

The Human Impact Behind Accessibility

Behind these rules are people trying to do simple things: check an account, complete a form, submit a request.

Users with low vision or some cognitive disabilities may rely heavily on predictable patterns to stay oriented. They remember where search usually appears, where the main button usually sits, and how navigation is arranged.

Keyboard and screen reader users build similar expectations over time. When focus jumps in ways that don’t line up with what they see on screen, they lose confidence in the layout. Some keep going, slowly. Others stop and leave.

How CSS Reordering Breaks Reading and Focus Order

Common CSS Features That Can Disrupt Logical Order and Accessibility

Most order-related issues come from a small set of tools we use all the time:
- position: absolute or position: fixed, which pull elements out of normal flow
- The order property in Flexbox and Grid
- flex-direction: row-reverse and column-reverse
- Grid behaviors like grid-auto-flow: dense, line-based positioning, and grid-template-areas
These features are useful, and sometimes necessary. Problems begin when they’re used to fix hierarchy or flow rather than just adjust appearance.

What This Looks Like in Practice

Navigation Example

Say the DOM order for your navigation is: Home, Contact, About, Blog.

Design wants “Contact” on the far right, so you use order in a flex container to produce: Home, About, Blog, Contact.

Visually, this layout looks correct. However, for a keyboard user, pressing Tab navigates in the following order: Home, Contact, About, Blog. This means focus jumps from Home to Contact (on the far right), then back to About and Blog (toward the center).

This jump is unexpected, as nothing on-screen explains why the focus shifts. Screen reader users also hear a sequence that doesn’t match the visual layout, making navigation confusing.

Card Layout Example

You have a grid of cards, and you want a “featured” card at the top. Instead of moving it in the DOM, you position it using Grid placement or position: absolute.

On screen, it appears first. In the DOM, it still sits midway through the list. Keyboard and screen reader users only encounter it after several other cards, even though the design is signaling that it’s the main item.

Screen Readers and Flex/Grid Nuances

Different browser and screen reader combinations handle Flexbox and Grid differently. Some combinations try to align with visual order in certain situations; others follow DOM order strictly. That behavior can also change over time as engines evolve.

The safe rule is simple: treat DOM order as the source of truth. If the order matters to the user, fix it in the markup, not just in CSS.

Real-World Patterns Where Things Go Wrong

These patterns show up often in production interfaces and quietly cause accessibility problems if no one is watching for them.

Global Navigation and Utility Links

Common issues in navigation and headers include:
- Moving “Contact,” “Sign in,” or “Cart” to the far right using order or reversed flex directions
- Placing search or language controls visually near the top, but leaving them late in the DOM
Keyboard users end up with a navigation path that feels out of sync with what they see.

Hero Sections, Promos, and Feature Blocks

Hero areas and promotional content can introduce similar gaps:
- A main hero button that visually looks like the first action but appears later in the DOM
- Promotional banners positioned over content but rendered late, so focus reaches them long after users expect
Design signals one priority; source order signals another.

Forms and Multi-Column Layouts

Multi-column forms look neat, but they’re easy to misalign structurally:
- DOM order runs all the way down the left column, then all the way down the right, while the visual layout suggests row-by-row reading
- Error messages or helper text appear far from the related fields in the DOM.
Screen readers end up reading labels, inputs, and messages in a confusing sequence.

Dashboards and Responsive Grids

Dashboards and grid layouts bring their own risks:
- Drag-and-drop widgets change visual position, but the DOM order stays the same.
- Product or article grids change column counts across breakpoints, but the underlying order still reflects the original layout.
Sighted users see one arrangement; keyboard and screen reader users move through another.

Designing Layouts That Keep Source & Visual Order in Sync

A helpful first check: if you remove all CSS, does the page still read in a sensible way from top to bottom?

Start with headings, landmarks, and content in a logical sequence. Use HTML elements that match their purpose, and add ARIA landmarks only when they’re truly needed. The better the structure, the easier everything else becomes.

Treat DOM Order as the Single Source of Truth

Set a clear expectation within your team:

If something needs to move for meaning or flow, change its position in the DOM instead of relying on visual reordering.

Reserve Flexbox/Grid order and absolute positioning for small visual refinements that don’t change the content’s meaning. When the markup matches the intended reading order, ongoing accessibility work stays much more manageable.

Mobile-First Thinking to Avoid Reordering Hacks

Designing from the smallest breakpoint forces you to decide what actually comes first in the linear flow. Once that order is set, larger layouts should build on it rather than fight it.

Instead of relying on row-reverse or heavy reordering to fix desktop layouts, adjust your HTML so each breakpoint builds on the same clear sequence.

When Visual and Logical Order Can Safely Diverge

There are places where visual and DOM order can differ without causing issues, such as:
- Independent articles or cards that don’t depend on each other
- Decorative elements whose position doesn’t change the meaning or task flow
Even there, keep focus order predictable within each unit and keep related elements together.

Responsive Design and the Reordering Trap

Responsive layouts often move panels around: sidebars shift from right to top, filters move above or below results, utility sections change position as the screen shrinks.

If those changes are made only with Flexbox or Grid reordering rather than structural changes, keyboard focus and reading order can feel out of sync with the visual layout. Over time, that chips away at accessibility across breakpoints.

Strategies to Avoid Paint-Over Layouts

A few practical habits help here:
- Prefer stacking and modest visual shifts over large reordering jumps.
- Decide early how content should flow linearly as the viewport changes.
- When you do reorder at a breakpoint, test that view with keyboard and assistive tech, not just by eye.
Emerging Tools: reading-flow and Future Support

New CSS features like reading-flow (currently available in some browsers) aim to align reading and focus order with visual order in flex, grid, and block layouts.

They’re promising, but support is still evolving. Treat them as enhancements, not a replacement for a clean structure. A clear DOM order will remain the more stable foundation.

Testing Reading and Focus Order in Everyday Workflows

Keyboard-Only Walkthroughs

One of the simplest and most useful tests is to set the mouse aside and use only the keyboard.

Tab through navigation, search, forms, checkout, and key dashboards. Watch for:
- Focus landing in unexpected places.
- Important elements are being skipped.
- Visible focus not matching what you would expect to come next.
This kind of quick check catches many accessibility issues long before formal testing.

Using Tools to Visualize Tab Stops and Sequences

There are tools and browser extensions that overlay numbers and lines to show the actual tab sequence. They make it easy to see when Flexbox, Grid, or positioning has produced a focus path that doesn’t match the design.

Adding these checks to regular QA is more effective than treating them as a one-time audit.

Screen Reader Spot-Checks

Short passes with a screen reader are also valuable. With NVDA, VoiceOver, or another option, move through key flows and confirm:
- Headings and regions follow a logical sequence.
- Instructions, labels, fields, and messages appear together in a sensible order.
Structural Smoke Tests in the Browser

For a quick structural check, temporarily disable CSS in dev tools or with an extension, then read the page in DOM order.

If it still makes sense, you likely have a solid base. If not, you’ve found a structural problem that is worth fixing before it spreads.

Fixing Existing Interfaces Without Starting From Scratch

Prioritize High-Risk Flows First

You don’t need to refactor everything at once. Start where order matters most:
- Global navigation
- Sign-up and sign-in flows
- Checkout and payment
- Important forms and dashboards
Compare how the layout looks with how keyboard focus and reading order actually move, and note the mismatches that affect meaning or task success.

Refactor Layouts to Respect Source Order

From there, adjust markup so the DOM reflects the intended order:
- Move sections in the HTML so they match the intended sequence.
- Group labels, fields, and messages together
- Replace heavy CSS-based reordering with patterns that rely on better structure.
This improves usability and gives you a more predictable layout to maintain long-term accessibility.

Bake Order Rules Into Your Design System

Your design system is a good place to codify these expectations:
- The visual and DOM orders should match by default.
- Exceptions must be documented and tested.
- Core layout components for nav, cards, and forms should ship with safe reading and focus patterns built in.
Continuous Improvements, Not One-Off Accessibility Cleanup

Order and focus shouldn’t be left to occasional audits. Add a few simple checks to code review:
- Does tab order match what we see?
- Are we using order, row-reverse, column-reverse, or absolute positioning in ways that might change meaning?
Where it fits, linting or CI rules can also flag risky layout patterns early.

Source Order: The Thing You Can’t Fake With CSS

When visual layout and DOM order stay aligned, interfaces feel calmer and easier to use. People can trust that what they see on screen matches what their keyboard and tools will encounter.

Small structural decisions—good HTML order, clear roles, careful use of layout features—can make a noticeable difference in both user experience, accessibility, and compliance.

If your team is planning a redesign, cleaning up legacy layouts, or just trying to understand where to focus first, you don’t have to figure everything out alone. An ADA-focused briefing with 216digital can help you map out your highest-impact order issues, connect them to legal risk, and build better habits into your ongoing design and development work.

When you’re ready, setting up that conversation can give your next release cycle a stronger foundation—visually, technically, and legally.
Greg McNeil

November 17, 2025

How-to Guides, WCAG Compliance

content order, How-to, User Experience, WCAG, WCAG conformance, web developers, web development
How Good Is Your Accordion Accessibility, Really?
You’ve seen it before — those long, scroll-heavy pages packed with information. Even with great content, the layout can feel like a wall of text. It’s easy to lose your place. Harder still to stay focused.

That’s why accordions became so popular. They let you tuck sections away, helping people find what matters without forcing them to wade through everything else. They keep things clean, organized, and easier to digest.

But here’s the trade-off: an accordion that isn’t coded for accessibility can lock people out instead of inviting them in. Keyboard users can get stuck. Screen readers might skip entire sections or misreport whether content is open or closed. What looks tidy on the surface can be chaotic behind the scenes.

In this article, we’ll walk through how to build an accordion that’s not just functional but genuinely inclusive. By the end, you’ll understand what good accordion accessibility looks like — and how small development choices make a big difference for real users.

The Anatomy of an Accordion

At its core, an accordion is simple:
- A header or button people click or focus on.
- A content panel that expands or collapses to show details.
These pairs usually live inside a wrapper — maybe a <div> or a <ul> if you want to give screen readers a count of how many sections there are. Adding an aria-label to that wrapper can help clarify that this group of buttons belongs together.

Here’s a basic structure:
```
<ul aria-label="Accordion Control Group">
  <li>
    <button aria-controls="panel1" aria-expanded="false" id="accordion1">Section One</button>
    <div id="panel1" hidden>
      <p>Content for this section.</p>
    </div>
  </li>
</ul>
```
Think of this as the skeleton. Once you have a clear hierarchy, you can start layering in keyboard behavior and ARIA states. Structure isn’t decoration — it’s how assistive technologies understand your layout and read it back to users. That’s the foundation of solid accordion accessibility.

Keyboard Navigation: Where Real Accessibility Begins

The keyboard test is where most accordions fall apart. If you can’t open, close, and move through the component using only a keyboard, something’s missing.

A few simple rules make all the difference:
- Enter or Space should open and close sections.
- Tab should move forward through headings and visible content.
- Shift + Tab should move backward through that same flow.
When a section collapses, focus should jump back to the button that opened it — not vanish into the page. And every focusable element needs a visible indicator, whether that’s an outline or a subtle highlight.

For longer accordions, a “Skip accordion” link above the section is a small courtesy that goes a long way. It lets keyboard users move past the entire block when they don’t need it.

A good gut check? Set your mouse aside. If you can comfortably navigate the entire component using only your keyboard, your accordion accessibility is already miles ahead.

Semantic HTML: Let Meaning Do the Heavy Lifting

A lot of accessibility work is about using the right tools from the start. Semantic HTML gives browsers and assistive tech the information they need without extra code.

Here’s one solid pattern:
```
<h3>
  <button
    type="button"
    aria-expanded="false"
    aria-controls="panel1"
    id="accordion1-button">
    Billing Details
  </button>
</h3>
<div id="panel1" role="region" aria-labelledby="accordion1-button" hidden>
  <p>Your billing information goes here.</p>
</div>
```
This approach works because:
- <button> is already accessible and keyboard-friendly.
- aria-controls connects the button to its panel.
- role="region" helps screen readers describe the area once it’s expanded.
If you add icons or arrows, hide them from screen readers with aria-hidden="true". They’re visual cues, not meaningful content.

When your markup already carries meaning, ARIA becomes a way to enhance — not patch — your accordion accessibility.

Getting ARIA Right

ARIA attributes are what make dynamic elements “talk” to assistive technology. Used well, they keep users informed about what’s changing on screen.

The essentials:
- aria-expanded shows whether a section is open or closed.
- aria-controls links the button to the content it manages.
- aria-hidden keeps hidden content out of the accessibility tree.
- aria-labelledby ties the panel back to its header.
Your JavaScript should keep these in sync. When a section opens, switch aria-expanded to “true” and remove the hidden attribute. When it closes, set it back to “false” and hide the content again.

Add some visual feedback — an arrow that rotates or a smooth transition — so the interaction feels cohesive for everyone.

Good accordion accessibility doesn’t just meet a spec; it creates a consistent, predictable experience no matter how someone browses.

Native vs. Custom: Choosing the Right Path

If you’re building something simple, the native <details> and <summary> tags might do everything you need. They’re semantic, keyboard-ready, and require almost no JavaScript.
```
<details>
  <summary>Return Policy</summary>
  <p>Most items can be returned within 30 days.</p>
</details>
```
The downside? Styling can be limited, and behavior may vary slightly across screen readers — especially on iOS.

For more complex use cases, like multi-step forms or sections that animate open one at a time, a custom setup gives you full control. Just remember that every bit of custom logic means you’re also responsible for maintaining the accessibility that native elements give you for free.

Putting It All Together

Imagine a checkout form split into three collapsible sections: Personal Info, Billing, and Shipping.

Each section uses a button with aria-expanded and aria-controls. Each panel has role="region" and a unique ID. When users open a section, screen readers announce “Billing section expanded,” and focus moves smoothly to the first field.

If JavaScript fails, the content is still visible and usable. That’s resilience — and it’s a hallmark of good accordion accessibility.

When you build this way, you’re not adding “extra” accessibility. You’re writing cleaner, smarter code that works for everyone.

Testing What You’ve Built

No accessibility checklist is complete without testing.

Manual Testing

Use only your keyboard. Confirm that focus behaves as expected and hidden panels can’t be tabbed into.

Screen Reader Testing

Run through your accordion with NVDA, JAWS, or VoiceOver. Listen for clear announcements of “expanded” and “collapsed” states.

Automated Tools

Tools like Lighthouse or WAVE can flag broken ARIA references, missing labels, or overlapping IDs. Automated scans are helpful, but they’re not the finish line. Real users will always notice things an algorithm won’t. The goal isn’t perfection — it’s progress and empathy in practice.

Keep Expanding Accessibility

When built with care, accessible accordions do more than tidy up a layout — they make a site feel calmer, smarter, and easier to use. They’re a small reminder that good code and good experience go hand in hand.

Every time you improve an interactive element, you make the web a little more welcoming.

If you’re ready to take a closer look at your site’s accessibility — from accordions to forms, modals, and beyond — schedule an ADA briefing with 216digital. We’ll help you identify where your code stands today and how to make accessibility part of your workflow going forward.
Greg McNeil

October 30, 2025

How-to Guides

Accessibility, accessible accordion, accordion, accordion accessibility, How-to, web developers, web development, Website Accessibility

How to Create Accessible Dialogs and Modals

You’ve probably clicked a button that suddenly stopped everything — a pop-up asking, “Are you sure?”Or maybe you’ve seen a small info box appear off to the side — helpful, but never in the way. Both are dialogs, designed to grab attention in different ways.

Used well, dialogs create clarity and focus. Used poorly, they interrupt, confuse, and make people feel stuck.

The HTML <dialog> element makes these patterns easier to build than ever before. But accessibility isn’t built into the code — it comes from the decisions you make around it. The choice between a modal and a non-modal dialog affects more than layout. It shapes how people experience trust, control, and flow within your interface.

This guide looks at when to use each and how to design accessible dialogs that feel natural, respectful, and human-centered — helping everyone move forward with confidence.

Modals vs. Dialogs: Key Differences and Use Cases

Every dialog creates a moment — a small pause in the user’s flow. Some moments need all of a person’s attention; others just need to offer quiet support in the background. The real skill lies in knowing which one your design calls for.

What’s the Difference?

A modal dialog asks users to stop what they’re doing and make a choice before continuing. When opened with showModal(), it locks focus inside and disables the rest of the interface. That’s not a flaw — it’s intentional. Modals are meant to protect important steps: confirming a deletion, submitting a form, or saving something that can’t be undone.

A non-modal dialog, opened with show(), works alongside the main content. It might appear as a sidebar, filter panel, or help window — something that adds clarity without breaking the user’s rhythm. The rest of the page stays usable, giving people control over how and when to engage.

Both patterns have value. The difference isn’t technical — it’s about the kind of experience you want to create. Modals demand attention. Non-modals share it.

When to Use Each

Modal Dialogs	Non-Modal Dialogs
Confirming destructive or irreversible actions	Providing optional settings or filters
Displaying critical warnings or alerts	Showing help text or guidance
Collecting essential information, like passwords or payments	Offering contextual tools that enhance workflow
Presenting legal or security confirmations	Sharing reference information while users continue working

Advantages and Drawbacks

Type	Advantages	Drawbacks
Modal Dialogs	• Keeps users focused on what matters most. • Prevents data loss or accidental actions. • Creates clear decision points. • Makes sure critical alerts are seen.	• Interrupts workflow and momentum. • Can frustrate or confuse if overused. • Requires careful focus handling for accessibility.
Non-Modal Dialogs	• Supports multitasking and flow. • Reduces cognitive strain by giving users control. • Feels less intrusive and more flexible.	• Important details might go unnoticed. • Not ideal for high-stakes actions. • Can clutter layouts if poorly managed.

Choosing the Right Type

When deciding between the two, ask yourself:

Does this moment need to stop the user, or simply guide them?

Use modals when you need someone to confirm, commit, or acknowledge something before moving on.
Choose non-modals when the goal is to assist or inform without interrupting their process.

Both serve accessibility — just in different ways. A well-timed modal can prevent errors. A well-designed non-modal can preserve flow. The goal isn’t to eliminate interruptions altogether, but to make every one of them intentional.

Accessible dialog design starts with empathy. Think about how people move through your interface — how they regain focus, how they understand what just appeared, and how much control they still have. When you build from that mindset, you’re not just meeting standards. You’re respecting your users’ attention, time, and agency.

Building Accessible Dialogs: From Code to Experience

Creating accessible dialogs isn’t about adding extra layers of code — it’s about protecting clarity and ease of use. The HTML <dialog> element already gives you a strong starting point. What you do next determines whether the experience feels effortless or confusing.

Start with Solid HTML

HTML gives you two built-in paths:

showModal() creates a modal dialog.
show() creates a non-modal dialog.

Both handle basic focus and background behavior automatically. From there, it’s all about refinement.

Always include a clear, labeled close button — and make sure it returns focus to the element that opened it.

<button id="close-dialog">Close</button>
<script>
  document.querySelector('#close-dialog')
    .addEventListener('click', () => myDialog.close());
</script>

It’s a small step, but it reinforces something bigger: giving users control — the foundation of every accessible experience.

Label Everything Clearly

Assistive technology depends on structure that makes sense. Every dialog should announce what it is, why it’s there, and how to leave it.

<dialog aria-labelledby="dialog-title" aria-describedby="dialog-desc">
  <h2 id="dialog-title">Confirm Action</h2>
  <p id="dialog-desc">This will permanently delete the record.</p>
</dialog>

If it’s an urgent message, add role="alertdialog" so screen readers read it immediately. Otherwise, keep the default role and double-check that:

The title and description are linked with aria-labelledby and aria-describedby.
The close button is labeled with text, not just an icon.
Focus moves logically when the dialog opens and closes.

When these pieces work together, the dialog doesn’t just appear — it communicates clearly, with purpose and respect.

Keep Focus on Track

Focus is where accessibility either shines or breaks.

When a dialog opens, the user’s focus should land directly inside it. When it closes, focus should return to the element that triggered it.

dialog.addEventListener('close', () => trigger.focus());

A few extra checks help keep that flow intact:

Tab and Shift+Tab should only move through active elements inside the dialog.
Escape should always close it.
Every interactive element should have a visible focus indicator.

If you’ve ever been trapped inside a modal with no way out, you already know why this matters. Freedom of movement — even within a small overlay — is core to accessibility.

Prevent Background Scrolling

When a modal appears, the world behind it should stay still.
Allowing the background to scroll while a dialog is open can disorient users, especially those relying on visual context or assistive technology.

A simple CSS rule can make all the difference:

body.modal-open {
  overflow: hidden;
}

Toggle that class when opening and closing the dialog. It’s a subtle fix that steadies the visual environment and prevents confusion — small detail, meaningful improvement.

Design for Visual Calm

Accessibility isn’t only technical — it’s visual. A dialog should direct attention, not demand it.

Use gentle layering, thoughtful contrast, and spacing that feels natural.

dialog::backdrop {
  background-color: rgba(0, 0, 0, 0.65);
}

Follow WCAG contrast guidelines:

4.5:1 for normal text
3:1 for large text

Soft shadows, calm edges, and balanced spacing help users focus on content without feeling overwhelmed. A well-designed dialog doesn’t shout — it invites. It says, “Look here, when you’re ready.”

That’s what visual accessibility feels like — respectful, intentional, and human.

Best Practices for Accessible Dialogs

Accessibility isn’t just about getting the mechanics right — it’s about how the experience feels. These best practices go beyond compliance to help you design accessible dialogs that feel considerate, consistent, and calm.

1. Keep Users Oriented

People should always know where they are. On larger screens, let a touch of the background remain visible so the dialog feels connected to the page. On mobile, a full-width layout often works better for readability and touch targets.

It’s about maintaining orientation — helping users feel connected to where they are, not suddenly somewhere else. When context stays visible, confidence follows.

2. Offer Multiple Ways Out

A good dialog respects autonomy. There should never be a sense of being trapped.

Include a clearly labeled “Close” button, let the Escape key work naturally, and if clicking outside dismisses the dialog, make sure screen readers announce that it closed.

The best dialogs don’t just let people leave — they make that exit easy to find, every time.

3. Use Restraint with Motion

Animation should support, not distract. Avoid heavy fades, blurs, or large shifts that feel like the page vanished.

A dialog should feel like a step forward, not a teleport. Subtle transitions — a soft fade or gentle scale — help users stay oriented and avoid triggering motion sensitivity.

If it feels smooth and steady, you’re doing it right.

4. Test Like a Real User

Once the dialog looks good, use it the way your audience will.

Try it with only a keyboard.
Run it with NVDA or VoiceOver.
Zoom in to 200% and see if anything disappears or becomes unreadable.

If something feels clunky or confusing, it is. Real testing turns assumptions into insight — and that’s where true accessibility takes shape.

5. Respect Timing and Intent

Never open modals automatically or stack several in a row. Give people time to think, act, and close things at their own pace.

Accessibility is as much about emotional comfort as it is about usability. Respecting timing and intent helps users feel calm and in control. That’s what good design does — it builds trust through patience.

Accessibility Beyond the Dialog

Dialogs and modals are moments of conversation between your site and your users. When they’re done right, they help people act confidently and stay in flow. When they’re not, they create friction and fatigue.

The best accessible dialogs are quiet — they guide without getting in the way. They respect focus, timing, and attention so users never have to think about accessibility; it’s already part of the experience.

At 216digital, we see accessibility as communication done right — designing in a way that includes everyone from the start. If your team is ready to move beyond checklists and create digital experiences that truly connect, schedule an ADA briefing with us today. Together, we’ll make accessibility a natural, lasting part of how your organization grows.

Greg McNeil

October 15, 2025

How-to Guides

Accessibility, accessible dialogs, How-to, web developers, web development

Can a Command Line Be Accessible by Design?
If you’ve spent any time in development, you know the command line is where things get real. It’s efficient, fast, and—let’s be honest—satisfying. That single blinking cursor has powered decades of progress. From deploying servers to pushing commits, the command line is still where we get work done.

But for all its simplicity, it isn’t always as accessible as it seems. Yes, it’s text-based. Yes, it’s keyboard-driven. Yet those strengths can be deceiving. For developers who rely on screen readers or braille displays, a CLI’s clean look can hide a mess of barriers: missing structure, unreadable tables, spinning animations that never speak.

Accessibility isn’t just a web problem—it’s a design principle. When a command line is an accessible CLI, it becomes what it’s always meant to be: a tool for everyone to build, create, and solve problems efficiently.

Why Accessibility Still Matters in the Command Line

A 2021 study by Google researchers Harini Sampath, Alice Merrick, and Andrew Macvean took a closer look at command-line accessibility for developers with visual impairments. What they found might surprise you: CLIs, for all their strengths, are far from friction-free.

Participants could technically complete tasks—but it took significantly more effort, time, and patience than expected. The issue wasn’t skill. It was design. CLIs are, by nature, streams of text with no built-in structure for assistive technology to interpret. There are no headings, no semantic anchors, no easy ways to navigate.

One developer summed it up perfectly: the CLI “works, but it’s tiring.” Most found themselves building workarounds—copying output into Notepad, exporting text to a browser, or writing custom scripts to make data readable.

And that’s really the heart of it: accessibility isn’t just about whether something can be used. It’s about whether it can be used well. That’s where building an accessible CLI from the start changes everything.

Where the Command Line Trips Up—and How to Fix It

The study’s findings highlight some clear patterns that every CLI developer can learn from. None of them require reinventing the wheel; they just ask for intention.

1. Structure Matters More Than You Think

We tend to think of text as automatically accessible—but not all text is equal. The command line outputs everything as flat strings. There’s no hierarchy, no markup, and no way for screen readers to interpret context.

Take man pages. They look structured, with headings and sections, but to a screen reader they’re just one long stream. Users can’t jump between sections or skim efficiently. Many developers in the study said they avoid man pages entirely and rely on web docs instead.

A simple solution? Offer structure where it’s missing:
- Provide HTML or Markdown versions of documentation.
- Add export options (--help-html, --manual-online).
- Allow users to format output as CSV or JSON for easy navigation.
A truly accessible CLI doesn’t stop at giving you data—it gives you data you can navigate.

2. Tables and Long Outputs Need Rethinking

Tables are a classic offender. They look organized, but they’re actually just rows of text spaced apart. For a screen reader, that structure disappears. Developers have to mentally map where each number belongs, remembering what every column represents.

That’s not accessibility—that’s endurance.

Better approaches include:
- A --flat or --no-table flag to simplify output.
- Options to export to structured formats (--output=csv, --output=json).
- Including clear, readable headers for every data point.
And for those endless command outputs? Let users redirect text to a file automatically (--export, --logfile, --view-html). Searching or filtering shouldn’t require stepping out of accessibility tools just to get the job done.

These simple changes turn a good CLI into a genuinely accessible CLI—one that respects how different users interact with information.

3. Feedback Should Be Informative—Not Decorative

Developers love a good spinner or progress bar. But when screen readers encounter those fancy progress indicators, they usually read something like “dot dot dot dot fail.”

In Google’s study, one developer said it best: “I could tell something was happening, but I didn’t know what.”

Instead of simulating motion, communicate progress with plain, descriptive text:

“Deploying container… 50% complete.”

“Success: VM created.”

And always give users an escape hatch: flags like --no-animation or --static-output keep feedback clean without slowing anyone down. A smart, accessible CLI never assumes sight is the only way to know something’s working.

4. Make Error Messages Clear and Human

If you’ve ever seen a CLI error filled with regex syntax, you can imagine how that sounds when read aloud: “left bracket A dash Z right bracket…”? Not exactly clear.

Error messages in the study were one of the most common frustrations. Developers spent hours debugging issues that could’ve been solved with one plain-language sentence.

Here’s the fix:
- Describe what happened, not just what failed.
- Offer actionable next steps.
- Keep symbols and regex out of default messages—reserve them for verbose or debug modes.
The goal isn’t to oversimplify; it’s to make sure the message is usable by everyone who reads—or hears—it.

Practical Guidelines for Designing an Accessible CLI

The study concludes with recommendations that align perfectly with inclusive design best practices.

Here’s how to apply them in your next CLI project:
1. Provide HTML versions of documentation: Treat --help and man outputs as summaries, not full references.
2. Let users export long outputs: Make it easy to redirect results to text, HTML, or CSV.
3. Document output structures: Explain what your CLI prints before users run it—help them form a mental model.
4. Make tables convertible: Offer ways to flatten or export tabular data for screen reader compatibility.
5. Always include progress and status updates: Never assume silence equals success.
6. Use progress indicators that read correctly: ASCII art may look fun, but it sounds like noise.
7. Write error messages that are understandable aloud: Avoid shorthand or syntax that doesn’t translate when spoken.
An accessible CLI isn’t a niche feature—it’s a sign of thoughtful engineering.

Start Where Developers Live: The CLI

Here’s the takeaway: accessibility isn’t a bonus; it’s good design. The same features that help someone using a screen reader—structured data, consistent output, clear feedback—help everyone who uses your tool. They make automation cleaner, logs easier to parse, and development faster.

Most importantly, they remove the unnecessary friction that holds good developers back.

At 216digital, we see accessibility as the foundation of quality, not the final coat of paint. Whether it’s your website, software, or CLI, inclusive design starts with asking a simple question: Can everyone use this the way it’s meant to be used?

If you’re building developer tools and want to make them as efficient as they are inclusive, schedule an ADA briefing with 216digital. We’ll help you test, refine, and design CLIs that truly work for everyone—from the first keystroke to the final command.
Greg McNeil

October 14, 2025

How-to Guides

Accessibility, accessible CLI, How-to, Web Accessibility, web developers, web development, Website Accessibility
Product Media Accessibility: Are You Doing It Right?
Visuals drive e-commerce—they shape how customers understand, compare, and connect with products. But for users relying on screen readers or other assistive technologies, those visuals only work when paired with accurate alt text and accessible labels. Without them, key product details disappear, leaving users unable to engage or buy.

Accessibility also drives measurable results. Research shows that 71% of users with disabilities leave sites that present barriers, while inclusive design reduces bounce rates and builds trust. Search engines benefit, too—HubSpot reported a 779% increase in image traffic after optimizing alt attributes. And with nearly 15% of the global population living with a disability, accessible images open your storefront to a wider audience that can browse and buy without friction.

When done well, accessibility becomes more than a technical fix—it’s a competitive advantage. It improves visibility, trust, and conversion, all while making your brand easier for everyone to experience.

This guide explores what that looks like in practice—how to make product media accessible, where teams most often slip, and how to integrate accessibility into your daily workflow.

What Makes a Product Media Accessible

High-quality product media isn’t just about presentation—it’s about communication. Every image should help shoppers understand your product, evaluate their options, and make confident decisions.

In accessible design, that means ensuring every photo, color variant, and product angle can be understood not only visually, but also through assistive technology.

Below are the key principles that make product media both effective and accessible.

1. Clear and Descriptive Alt Text

Alt text gives images meaning. Without it, assistive technologies have nothing to announce—and essential product details disappear. Descriptive alt text ensures that shoppers who rely on screen readers can access the same information as anyone else.

When written thoughtfully, alt text also supports SEO, helping search engines understand what’s being shown and improving how your products appear in image searches.

If you’re coding manually, add the alt attribute directly to your <img> tag:
```
<img src="example.jpg" alt="A description of the image">
```
Keep descriptions concise but specific, focusing on what’s visually relevant to the shopper.

For those using a CMS like Shopify, WordPress, or Magento, you can add this text in the Alt Text or Alt Description field during upload. Many platforms support bulk editing—an efficient way to replace missing or generic alt text and ensure consistency across your catalog.

When Product Media Need Alt Text (and When They Don’t)

Product photos are the foundation of any e-commerce experience. They convey material, color, and quality—all the details a shopper depends on. Because of that, almost every product media needs alt text.

The only exception is when an image adds no new visual information—for instance, when showing the same product from another angle without revealing new features or details.

Redundant Product Views

Multiple images of the same item are common: front, back, side, or top-down shots. These angles help sighted users but can become repetitive when read aloud by screen readers.

If each image shows the same product with no meaningful change, you can mark the duplicates as decorative with an empty alt attribute:
```
<img src="product-side.jpg" alt="">
```
This signals assistive technologies to skip the image without disrupting the experience. Just ensure that at least one image—usually the primary product photo—has full, descriptive alt text.

Does Your Image Need Alt Text?

If an image adds context or new information that could influence a shopper’s decision, it must have its own alt text.

Ask: Would this image help someone understand or evaluate the product differently? If so, describe it.

Examples include:
- Different colors or finishes:
  “Red ceramic table lamp with linen shade” vs. “Blue ceramic table lamp with linen shade.”
  Each variant should have distinct alt text.
- Unique features or components:
  If an image highlights stitching, a removable part, or a texture, mention it briefly.
- Lifestyle or context photos:
  When a photo shows the product in use—like a jacket being worn or a sofa in a living room—include that context to communicate scale and purpose.
- Images with embedded information:
  If an image includes text such as a sale banner, sizing chart, or label, that information must also appear in alt text or nearby HTML. Screen readers cannot interpret text embedded in images.
Writing Effective Alt Text

Good alt text is concise, factual, and written with purpose. It shouldn’t describe every detail—just what matters to understanding the product.

Best practices include:
- Keep descriptions under 125 characters when possible.
- Avoid phrases like “image of”—screen readers already announce it.
- Use specific, factual terms: “brushed,” “polished,” “textured,” “matte.”
- Mention what changes between images, such as angle or color.
- Adjust wording for context—a banner image may need different phrasing than a gallery thumbnail.
A consistent alt text style guide helps teams stay aligned, especially when managing large catalogs or working across departments.

2. Optimizing Product Media Formats for Accessibility

Accessibility also depends on clarity and performance. Large, slow-loading images can undermine user experience, particularly on mobile.

Use formats that balance quality and speed:
- WebP delivers high-quality visuals with efficient compression, improving load times.
- SVG is ideal for scalable graphics such as logos or icons, maintaining crispness on any screen size.
Fast, responsive images ensure your store remains usable across devices and assistive technologies alike.

3. Avoiding Text Embedded Within Images

If an image includes text—like promotional banners, product specs, or sale messages—screen readers can’t interpret it.

Keep all essential text in HTML or nearby captions.
If embedded text is unavoidable, repeat the information in the image’s alt text or elsewhere on the page so that it’s accessible to every shopper.

4. Maintaining Visual Clarity and Contrast

A clean, modern aesthetic is appealing—but not if it sacrifices visibility.

Low-contrast product photos (for instance, light gray items on a white background) can be difficult for users with low vision to see.

Maintain at least a 4.5:1 contrast ratio between the product and its background. Adding subtle shadows, reflections, or gradient overlays can improve visibility without compromising your design aesthetic.

5. Labeling Interactive Product Media

Any clickable image or icon—such as a “zoom” button, “add to cart” symbol, or “view gallery” thumbnail—should have an accessible name or aria-label.

Describe the action, not the appearance:
- “Zoom product image”
- “Add to cart”
- “Open gallery view”
These small details help users navigate your site predictably and confidently, no matter how they interact with it.

Testing Tools and Workflow Integration

Accessibility isn’t a one-time audit—it’s an ongoing habit built into your development process.

Automated tools:
- WAVE and Lighthouse in Chrome DevTools identifies barriers and improvement tips for each image.
Manual checks:
- Test your pages with NVDA, VoiceOver, or JAWS to hear how descriptions are announced.
- Disable images in your browser and ensure text alternatives still convey essential information.
Workflow tip: Integrate accessibility validation into CI/CD pipelines. Use pre-commit hooks or CMS checks to block uploads missing alt attributes. Over time, this normalizes accessibility as part of the build process—not an afterthought.

Product Media That Speaks to Every Shopper

Accessible product media is about more than compliance—it’s about communication. Every shopper, regardless of ability, deserves the same opportunity to understand your products clearly and confidently.

From writing meaningful alt text to maintaining contrast and responsive performance, accessibility transforms static visuals into tools that inform, guide, and convert. It strengthens trust and creates smoother experiences across every device and interaction.

When your product media works for everyone, your brand stands out for the right reasons: clarity, quality, and care.

If you’re ready to assess your current approach or bring accessibility into your creative workflow, schedule an ADA briefing with 216digital. We’ll help you turn accessibility from a checklist into a lasting standard for digital craftsmanship.
Greg McNeil

October 13, 2025

How-to Guides

Accessibility, How-to, product media, WCAG, Web Accessibility, web developers, web development, Website Accessibility
What Is Visually Hidden Content—and Why Use It?
Every interface makes choices about what to show and what to leave unseen. Most of the time, that’s about layout or aesthetics—but it’s also about communication.

For users who rely on assistive technologies, much of that communication happens through structure, labels, and semantic relationships. When visual clarity comes at the cost of semantic clarity, accessibility starts to break down. A clean UI is great, but clarity for assistive technologies is non-negotiable. When we drop visible text in favor of icons or compact layouts, we still owe users the same meaning.

A practical answer is visually hidden content. It’s a technique for keeping information available to assistive tech—screen readers, braille displays, voice navigation—while keeping it out of visual view. Done well, it bridges the gap between a clean interface and a complete experience.

You’ve seen it everywhere:
- A magnifying glass icon that announces “Search.”
- A “Read more” link that includes the article title.
- A skip navigation link that quietly appears when tabbed into.
Each example keeps the design clean while preserving meaning for users who don’t navigate visually. It’s not a trick—it’s thoughtful design expressed through code.

When Hiding Breaks Accessibility

It’s tempting to reach for display: none or visibility: hidden. Both make an element disappear—but they also remove it from the accessibility tree. To a screen reader, that content no longer exists.

The same problem appears in older workarounds—moving elements off-screen with huge negative positioning or marking the wrong element with aria-hidden="true". They achieve visual cleanliness but erase meaning for assistive tools.

If the accessibility tree is a map of what users can explore, those declarations tear off a corner of it. The HTML remains, but users can’t reach it.

When something needs to be read, referenced, or focused, it must stay in the tree. The goal isn’t to hide it from everyone—it’s to make it visually invisible while still programmatically present.

A Modern, Reliable Pattern for Visually Hidden Content

Most modern teams rely on a single, standardized utility for this purpose. It’s simple, maintainable, and works across browsers and devices:
```
.visually-hidden {
  border: 0;
  clip-path: inset(50%);
  height: 1px;
  margin: 0;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}
```
Each property plays a specific role:
- clip-path: inset(50%) hides the visible area.
- position: absolute removes it from the layout but not the accessibility tree.
- height and width shrink it to an imperceptible size.
- overflow: hidden ensures no text leaks visually.
- white-space: nowrap prevents wrapping or accidental exposure.
This approach replaced older hacks like clip: rect() or sending text off-screen with left: -9999px;. Those caused issues for magnifiers and high-zoom environments. The clip-path pattern is clean, modern, and predictable.

Use it with intention. Adding visually hidden content everywhere can overwhelm screen reader users. The best implementations give context—not clutter.

Making Focusable Elements Work for Everyone

Skip links, “Back to top” anchors, and similar utilities need to stay hidden until they’re actually used. If you apply .visually-hidden directly, keyboard users can focus the link but won’t see it—an invisible focus trap.

The solution is a focusable variant:
```
.visually-hidden-focusable:not(:focus):not(:active) {
  border: 0;
  clip-path: inset(50%);
  height: 1px;
  margin: 0;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}
```
This keeps the element hidden until it receives focus. Once active, it becomes visible—making skip links discoverable without cluttering the design.

A few practical habits:
- Always provide a visible focus outline and clear contrast.
- Keep the revealed link’s position consistent (usually top-left).
- Use short, direct text—users should immediately understand its purpose.
This small adjustment is what makes keyboard navigation intuitive, discoverable, and consistent across accessible websites.

Visually Hidden or ARIA? Understanding the Difference

Developers sometimes treat these tools as interchangeable. They’re not; they work at different layers.

Use visually hidden content when you need real, localizable text in the DOM—context for links, helper hints, or dynamic status messages that assistive technologies should read naturally.

Use ARIA when you’re labeling or describing elements that are already visible:
- aria-label adds a brief text label.
- aria-labelledby points to a visible label.
- aria-describedby links to explanatory text or error messages.
- Live regions (role="status") announce dynamic changes.
Often, the best solution combines both. A decorative SVG can be marked aria-hidden="true", while a hidden text label provides a proper name. A form field can have a visible label and connect to hidden guidance via aria-describedby.

Knowing when to use which—sometimes both—is what turns compliance into genuine usability.

Writing Hidden Text That Adds Value

Hidden text should earn its place. It’s part of the user experience and deserves the same editorial care as visible copy.

A few best practices:
- Add what’s missing visually—don’t repeat what’s obvious.
- Keep it short and natural; users will hear it read aloud.
- Avoid filler or redundancy—screen readers already announce role and state.
- Localize it so it fits each supported language context.
When written thoughtfully, visually hidden content enhances understanding without adding noise. The best examples are invisible to some, indispensable to others.

Testing What You Can’t See

Accessibility isn’t a box to tick—it’s a conversation between your design and your users. Testing is where that conversation becomes real.

Here’s how to validate your implementation:
- Keyboard: Tab through the page. Ensure focus moves logically and stays visible.
- Screen readers: Use NVDA, VoiceOver, or JAWS to confirm that hidden text reads in context.
- Accessibility tree: Check DevTools to make sure hidden content remains part of the structure.
- Zoom and magnification: Scale up to 200% and confirm no visual artifacts appear.
Automation can’t tell you whether your content makes sense—but a quick, human pass will.

From Utility to System

Once you’ve validated your approach, make it part of your toolkit.
- Include .visually-hidden and .visually-hidden-focusable in your design system.
- Document their purpose, examples, and edge cases.
- Encourage teammates to review hidden content with the same care as visible UI text.
Frameworks like Tailwind’s sr-only class use this exact foundation. Aligning with established patterns makes your code predictable and your accessibility practices easier to scale.

This is how visually hidden content becomes part of your craft—not just a snippet you copy-paste.

The Invisible Work That Shapes Experience

A few quiet lines of CSS can completely change how people experience your site. Visually hidden content doesn’t alter what most users see, but it transforms what others can access, understand, and trust.

That’s what accessibility is really about—creating clarity that transcends sight. And that’s what good front-end work does at its best: it makes meaning visible, even when the code itself is unseen.

If you’re working through accessibility fixes or want a second set of eyes on remediation, consider scheduling an ADA briefing with 216digital. It’s a focused, collaborative session designed to help you identify barriers, prioritize what matters most, and move confidently toward compliance.
Greg McNeil

October 8, 2025

How-to Guides

Accessibility, How-to, visually hidden content, WCAG, Web Accessibility, web developers, web development

aria‑selected: Practical Guide for Interactive UI

Modern web applications thrive on interactivity. Tabs, listboxes, and data grids make complex tasks easier for sighted users—but without proper semantics, those same widgets can shut people out.

For example, a set of tabs may look visually distinct, but unless screen readers know which tab is currently selected, the component is unusable for blind users. Similarly, keyboard-only users can be stranded if selection isn’t tied to focus and navigation logic.

That’s where aria-selected comes in. This attribute bridges the gap between visual presentation and assistive technology, ensuring state changes are clearly communicated. In this guide, we’ll cover what aria-selected means, when to use it, real-world code examples, and best practices for building accessible interactions.

Decoding aria-selected

According to the WAI-ARIA specification, aria-selected communicates the selection state of an element in a widget. It doesn’t change visuals—it adds semantic meaning to the accessibility tree so assistive tech can interpret the UI correctly.

Values Explained

true → This item is selected.
false → This item is selectable but not selected.
(Absence) → This item isn’t selectable at all.

Tip: Roles that support aria-selected include: tab, option, row, gridcell, and treeitem. Use it only where a “selected” state makes sense.

aria-selected vs. Other Attributes

It’s easy to confuse aria-selected with other ARIA attributes. Here’s how to know when you’re using the right one:

Attribute	Primary Purpose	Typical Components
aria-selected	Indicates which item is currently chosen	Tabs, listboxes, grids, tables
aria-checked	Binary on/off state	Checkboxes, radios
aria-pressed	Toggle button active state	Toolbar buttons
aria-current	Denotes user’s current location	Nav links, breadcrumbs

Practical Use Cases & Code

Tabs

Tabs are a classic single-select widget. Only one tab can be selected at a time.

<div role="tablist" aria-label="Profile sections">
  <button id="tab-overview" role="tab" aria-selected="true"
          aria-controls="panel-overview">Overview</button>
  <button id="tab-settings" role="tab" aria-selected="false"
          aria-controls="panel-settings">Settings</button>
</div>

<div id="panel-overview" role="tabpanel" aria-labelledby="tab-overview">
  <!-- Overview content -->
</div>
<div id="panel-settings" role="tabpanel" aria-labelledby="tab-settings" hidden>
  <!-- Settings content -->
</div>

Implementation Notes

On click, Enter, or Space: update aria-selected, swap focus, and show the panel.
Keyboard navigation: Left/Right (or Up/Down for vertical), Home/End for quick jumps.

Listbox (Multi-Select)

Listboxes can be single- or multi-select. Here’s a multi-select version:

<ul role="listbox" aria-label="Choose toppings"
    aria-multiselectable="true" tabindex="0"
    aria-activedescendant="opt-pepperoni">
  <li id="opt-pepperoni" role="option" aria-selected="true">Pepperoni</li>
  <li id="opt-mushroom"  role="option" aria-selected="false">Mushrooms</li>
  <li id="opt-olive"     role="option" aria-selected="false">Olives</li>
</ul>

Interaction Details

Arrow keys move focus; aria-activedescendant updates to track the active item.
Space toggles selection state.
Ctrl/Shift + Arrow supports range selection like desktop apps.

Grids / Spreadsheets

Grids allow row and cell-level navigation. They’re common in dashboards and spreadsheets.

<div role="grid" aria-label="Sales records" aria-activedescendant="cell-1-2">
  <div role="row">
    <div role="columnheader" aria-colindex="1">Date</div>
    <div role="columnheader" aria-colindex="2">Sales</div>
  </div>

  <div role="row" aria-rowindex="1">
    <div id="cell-1-1" role="gridcell" aria-colindex="1" aria-selected="false">Jan</div>
    <div id="cell-1-2" role="gridcell" aria-colindex="2" aria-selected="true">5 000</div>
  </div>
  <div role="row" aria-rowindex="2">
    <div id="cell-2-1" role="gridcell" aria-colindex="1" aria-selected="false">Feb</div>
    <div id="cell-2-2" role="gridcell" aria-colindex="2" aria-selected="false">4 200</div>
  </div>
</div>

JavaScript Must Handle

Arrow keys move focus across cells and sync aria-activedescendant.
Space/Enter toggles aria-selected.
Optional: persist state (e.g., in localStorage) to remember selections.

Best Practices for aria-selected

Focus Management

In single-select widgets: focus stays inside, arrow keys update selection.
In multi-select widgets: focus moves independently, Space/Enter toggles states.
Always update aria-activedescendant dynamically.

Visual Feedback Beyond Color

Don’t rely on color alone. Use icons, bold text, or borders.
WCAG 2.2 requires at least 3:1 contrast for selected/focus states.

Keyboard Navigation

Tabs: Arrow keys, Home/End, Enter/Space to activate.
Listbox/Grid: Arrow keys plus Space/Enter (and Ctrl/Shift combos for multi-select).
Optional: Escape to clear selection or exit.

Testing Your Implementation

Accessibility doesn’t stop at code—it must be validated.

Screen reader testing: NVDA, JAWS, and VoiceOver should announce selection changes correctly.
Keyboard walkthroughs: Confirm focus order and selection behavior.
Automated checks: Useful for catching missing attributes, but always supplement with manual testing.

Bonus Patterns

Once you’re comfortable with the basics, aria-selected can also power:

ARIA Trees: File explorer-like navigation.
Carousels: Tabs-like controls for slide navigation.
Email-style panels: Combining aria-selected with aria-multiselectable for Gmail-style selection logic.

Build with Inclusion from the Start

The aria-selected attribute may seem small, but it represents a bigger principle: creating interfaces where everyone can interact equally.

Accessibility is about thoughtful interaction design, not just compliance checklists. By implementing aria-selected correctly, you close the gap between a slick UI and one that’s truly inclusive.

Don’t wait until launch—or worse, until a lawsuit—to think about accessibility. Build it in from the beginning, and both your users and your future self will thank you.

Want clarity on how your site measures up or how to improve implementation? Schedule a private ADA briefing with 216digital and get expert insight on real-world accessibility practices.

Greg McNeil

September 29, 2025

How-to Guides, Uncategorized

Accessibility, ARIA, aria-selected, web developers, web development, Website Accessibility

Buttons vs Links: Who Gets the Last Click?
You’ve got a component to wire up and a design that looks like… a rectangle with text in it. Classic. Do you reach for <button> or <a>? For a mouse user, either might “work.” For a keyboard user or someone on a screen reader, the wrong choice is a booby trap. Picture a user pressing Space on something that looks like a button and nothing happens, or hearing “Link” and suddenly a file gets deleted. That gap between what an element promises and what it does is where trust dies. By the time you ship this, you should be able to look at any interactive element and decide between buttons vs links without second-guessing.

The Rule Behind Buttons vs Links

There’s one rule worth tattooing on your coding hand:

Links go places. Buttons do things.

If an interaction navigates to a new location (a different route, an external page, a same-page anchor, or a file), it’s a link. If it performs an action on the current page (submits, toggles, opens, closes, mutates UI, updates data), it’s a button. Keep that mental model tight and the rest—semantics, keyboard behavior, screen reader expectations—snaps into alignment.

Let’s make that concrete. Screen readers announce name and role. “Link” tells the user to expect navigation; “Button” says “an action is about to happen.” Keyboard support follows suit: links activate with Enter; buttons activate with Enter and Space. That difference isn’t trivia—it’s the platform contract.

Why This Tiny Decision Matters More Than It Looks

First, semantics affects product quality. When the role and behavior match, users trust your interface—especially users who navigate by role (“jump me to the next button”). Second, robustness. A real link with a real href will still navigate if JavaScript takes a day off. A real button with type="submit" will submit the form without your custom event handlers. Getting buttons vs links right means your UI remains reliable under bad Wi-Fi, flaky extensions, or partial loads.

And yes, standards. Mislabeling roles or breaking keyboard activation is how you wander into WCAG failures like 2.1.1 (Keyboard) or 4.1.2 (Name, Role, Value). It’s not about box-ticking; it’s about delivering predictable, testable behavior.

When It Should Be a Button

If the thing does something on this page, start with <button>. That covers submitting a form, opening a modal, toggling a menu, expanding an accordion, saving a record, deleting an item, starting a fetch, pausing media—anything that changes state without changing URL.

Here’s what not to do:
```

<a href="#" onclick="submitForm()">Submit</a>
```
This announces as “link,” ignores the Space key unless you recreate that yourself, and fails if JavaScript is blocked. Use the element that already does the job:
```

<button type="submit">Submit</button>
```
Toggles are another frequent offender. If you’re opening and closing a menu, use a button and reflect state:
```
<button
  type="button"
  aria-expanded="false"
  aria-controls="mainmenu"
  id="menubutton">
  Menu
</button>

<nav id="mainmenu" hidden>…</nav>
```
When you flip the menu, flip aria-expanded and manage the hidden attribute. Users get the correct announcement, and you get keyboard support for free.

A quick style note while we’re here: don’t remove the focus outline unless you replace it with something obvious. Minimalism is lovely; invisible focus isn’t.
```
button:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 3px;
}
```
When It Should Be a Link

If the action navigates—new page, external site, file download, or a jump within the same page—reach for <a> with a real href. That gives you built-in affordances like “open in new tab,” a visible status bar URL, and the user’s browser history doing its thing.

Bad pattern:
```

<button onclick="location='/about'">Learn more</button>
```
Fix it:
```

<a href="/about">Learn more</a>
```
A few patterns that absolutely belong to links:
- Skip links: let keyboard users bypass repeating navigation.
```
 <a href="#main" class="skip-link">Skip to main content</a>
<main id="main">…</main>
```
- Downloads: if you can link it, link it.
```
 <a href="/report.pdf" download>Download report (PDF)</a>
```
- Breadcrumbs and primary nav: always links. Users expect middle-clicks and new tabs to work.
Give the link text meaning. “Click here” ages badly outside its paragraph. “Download Q3 report (PDF)” holds up wherever a user encounters it—like a screen reader’s Links List.

Styling Without Lying: Buttons vs Links in Disguise

Design will ask you to make links look like buttons or vice-versa. That’s fine visually, as long as the semantics don’t lie. If it navigates, keep it an <a>—then style it like a button. If it acts, keep it a <button>—then style it to match your theme. Users might not see the markup, but assistive tech will, and so will your QA.

A few constraints worth honoring while you polish:
- Don’t rely on color alone to signal “this is a link.” Underlines or a small icon are your friends.
- Keep contrast sane (think 4.5:1 for normal text). Your future self, reading in sunlight, says thanks.
- Targets should be comfortably tappable—around 44×44 CSS pixels is a good baseline.
- Maintain a visible focus style. If you nuke it, put a better one back.
Testing the Decision: Buttons vs Links Under Real Inputs

Automated tools are a fast smoke test—Lighthouse or WAVE will happily rat out missing names, broken contrast, or off-screen focus. Treat them as lint for accessibility. They won’t catch intent.

Intent is a manual game:
- Screen reader pass: with VoiceOver (macOS/iOS), NVDA or JAWS (Windows), confirm elements announce the correct role and name: “Button, Submit,” not “Link, Submit.”
- Keyboard pass: tab through. Links should activate with Enter; buttons with Enter and Space. Watch focus—no disappearing acts.
- Voice control: say “Click Submit” or “Go to Pricing,” and make sure the right control responds by name.
If any of those feel off, they are off. Fix the semantics first; the bugs usually evaporate.

Real-World Fixes That Come Up in Code Reviews

Most bugs we see with buttons vs links boil down to “we styled the wrong element” or “we tried to be clever with roles.” Two quick refactors cover a lot of ground:

Submitting with an anchor:
```

<a href="#" onclick="submit()">Submit</a>


<button type="submit">Submit</button>
```
Menu toggles built on anchors:
```

<a href="#" onclick="openMenu()">Menu</a>


<button type="button" aria-expanded="false" aria-controls="mainmenu">Menu</button>
```
If you truly, absolutely must build a custom control—and you’ve checked that <button> won’t cut it—own the keyboard and state explicitly:
```

<div role="button" tabindex="0" aria-pressed="false" id="play">Play</div>
<script>
const el = document.getElementById('play');
el.addEventListener('keydown', (e) => {
  if (e.key === ' ' || e.key === 'Enter') { e.preventDefault(); el.click(); }
});
el.addEventListener('click', () => {
  const next = el.getAttribute('aria-pressed') !== 'true';
  el.setAttribute('aria-pressed', String(next));
});
</script>
```
That’s a lot of ceremony to re-implement what <button> just… does. Treat this as a last resort.

A Short Checklist (Pin It Next to Your Linter)
- Navigation? <a href="…">. Action? <button>.
- Make the accessible name obvious: visible text or a clear aria-label.
- Preserve expected keyboard behavior (Enter vs Enter+Space).
- Keep focus visible and movement logical.
- Prefer native elements; avoid role-swapping unless there’s no alternative.
Wrapping It Up

Interfaces are a web of tiny decisions, and this is one of the tiniest. But consistent, honest semantics make everything else easier: testing, maintenance, onboarding new devs, and—most importantly—using the thing. Treat buttons vs links as a contract. Say what the element is, and make sure it behaves that way across mouse, keyboard, screen readers, and voice.

If you want a quick heuristic while you code: would a middle-click make sense here? If yes, it’s probably a link. Would “Click Submit” make sense to a voice user? If yes, it’s probably a button. Keep those instincts sharp and your UI will feel clean, resilient, and respectful by default.

If your team wants a second set of eyes on patterns like these—or you need help pressure-testing components before they scale—216digital is happy to jump in. Schedule an ADA briefing and we’ll help you turn the “tiny” choices into durable, inclusive defaults.
Greg McNeil

September 16, 2025

How-to Guides

Accessibility, Accessible Buttons, Links, Web Accessibility, Web Accessible Links, web developers, web development, Website Accessibility

Why Your Theme Choice Shapes More Than Just Design

What “Accessible” Really Means in Practice

Common Problems You’ll See When You Test Themes

WooCommerce Themes With Better Built-In Accessibility

Storefront

Neve

Responsive

OceanWP

Eimear and Monument Valley

How to Vet a Theme’s Accessibility Quickly

Do a Full Keyboard Tour

Check Headings and Landmarks

Test Forms and Messages

Zoom and Shrink

Fixing Gaps When Your Theme Is “Almost There”

How to Maintain Accessibility After Launch

Your Theme Is the Start—Accessibility Is Ongoing

What a 404 Really Is — and Why It Happens

Principles Before Pixels: A High-Performing 404 page Experience

1. Accessibility is Not Optional

2. Clarity First, Personality Second

3.Stay On-brand

4. Focus On Recovery, Not Apology

Accessibility Must-Haves for an Accessible 404 page

A Clear Statement of What Happened

A Layout That Still Feels Like “Your” Site

Recovery Paths That Are Easy to Spot and Use

Text and Visuals That Hold Up Under Strain

A Moment That Stays Stable, Not Jumpy

Page Anatomy: What to Include on Your 404 page

Under the Hood: Technical Details That Support the Experience

Analytics, Monitoring, and Continuous Cleanup

Governance: Building Habits That Reduce Future 404s

Not All Wrong Turns Are Dead Ends

Why Content Order Matters More Than It Looks

How Assistive Technologies See Your Layout and Accessibility

WCAG’s View: Meaningful Sequence, Focus Order, and Accessibility

The Human Impact Behind Accessibility

How CSS Reordering Breaks Reading and Focus Order

Common CSS Features That Can Disrupt Logical Order and Accessibility

What This Looks Like in Practice

Navigation Example

Card Layout Example

Screen Readers and Flex/Grid Nuances

Real-World Patterns Where Things Go Wrong

Global Navigation and Utility Links

Hero Sections, Promos, and Feature Blocks

Forms and Multi-Column Layouts

Dashboards and Responsive Grids

Designing Layouts That Keep Source & Visual Order in Sync

Treat DOM Order as the Single Source of Truth

Mobile-First Thinking to Avoid Reordering Hacks

When Visual and Logical Order Can Safely Diverge

Responsive Design and the Reordering Trap

Strategies to Avoid Paint-Over Layouts

Emerging Tools: reading-flow and Future Support

Testing Reading and Focus Order in Everyday Workflows

Keyboard-Only Walkthroughs

Using Tools to Visualize Tab Stops and Sequences

Screen Reader Spot-Checks

Structural Smoke Tests in the Browser

Fixing Existing Interfaces Without Starting From Scratch

Prioritize High-Risk Flows First

Refactor Layouts to Respect Source Order

Bake Order Rules Into Your Design System

Continuous Improvements, Not One-Off Accessibility Cleanup

Source Order: The Thing You Can’t Fake With CSS

The Anatomy of an Accordion

Keyboard Navigation: Where Real Accessibility Begins

Semantic HTML: Let Meaning Do the Heavy Lifting

Getting ARIA Right

Native vs. Custom: Choosing the Right Path

Putting It All Together

Testing What You’ve Built

Manual Testing

Screen Reader Testing

Automated Tools

Keep Expanding Accessibility

Modals vs. Dialogs: Key Differences and Use Cases

What’s the Difference?