How-to Guides Archives/Category

Why ARIA Alone Won’t Fix Your Website’s Accessibility
ARIA (Accessible Rich Internet Applications) has become a mainstay in modern front-end work, giving us a way to make complex interfaces more usable for people relying on assistive tech. But here’s the catch: despite how widely it’s used now, accessibility issues on the web haven’t actually gone down. In fact, reports like the annual WebAIM Million consistently show that pages using ARIA often rack up more accessibility errors than those that don’t. That’s a red flag—and it raises an important question: if ARIA is meant to improve accessibility, why does more ARIA so often lead to worse outcomes?

What ARIA Is—and What It’s Supposed to Do

At its core, ARIA is just a spec for adding semantic meaning where HTML alone doesn’t cut it. When we build custom UI components—think tab lists, modals, or live regions—ARIA roles and attributes tell screen readers what those elements are, how they behave, and when their state changes.

For example, aria-live lets us announce new content to screen readers without forcing a page reload. aria-label gives an accessible name to elements that don’t have visible text. Using role="tablist" clarifies the relationship between grouped tab controls. When used correctly, these attributes bridge the gap between how something looks visually and how it’s experienced non-visually.

When Is It Necessary?

There are valid cases where ARIA is the right tool—like custom widgets that don’t exist in native HTML, dynamic content that needs to be announced, or modal dialogs that require managing focus. In these edge cases, it can give essential context to assistive tech users. The trick is restraint: only reach for ARIA when HTML alone can’t deliver the behavior you need.

Why It Shouldn’t Be the Default Tool

The W3C’s first rule of ARIA is dead simple: “Don’t use ARIA if you can use native HTML.” There’s a reason for that. Semantic elements like <button>, <nav>, and <input> come with baked-in keyboard support, focus behavior, and screen reader semantics.

Replacing these with <div>s or <span>s and trying to patch on ARIA roles is a recipe for trouble. It adds complexity we have to maintain, and it increases the cognitive load on assistive tech users, who now have to deal with custom keyboard logic or missing states that native elements would have handled out of the box.

Common ARIA Misuse That Breaks Accessibility

Misusing ARIA is the fastest way to make things worse. Some of the most common mistakes we see:
- Redundant ARIA: e.g. adding role="button" on a native <button>, which can confuse announcements.
- Incorrect roles or attributes: like using aria-checked on something that’s not checkable.
- Static ARIA states: setting aria-expanded="true" and never updating it when the element collapses.
- Overriding native behavior : trapping focus or breaking expected tab order.
- Misused aria-hidden: This one’s especially nasty. It hides content from assistive tech, which is fine for decorative icons or offscreen helper text. But if you throw it on meaningful content like links or form controls, it removes them from the accessibility tree entirely. That creates “empty” focusable elements and violates the rule that aria-hidden="true" must never be on focusable items.
Take a link that only has an SVG icon with aria-hidden="true". Visually it looks fine, but to a screen reader, it’s just an empty link with no name. Compare that to a native <button> with either visible text or an aria-label—it automatically conveys its purpose. Misusing it like this doesn’t just fail to help; it strips meaning away.

Why ARIA Usage Correlates with More Errors

The WebAIM Million keeps showing the same trend: pages with ARIA average almost twice as many detectable errors as those without. That doesn’t mean ARIA is inherently bad—it means it’s often used wrong.

Here’s why that happens so often:
- More moving parts: Every ARIA attribute is another thing that has to stay in sync as the UI changes.
- Misunderstood implementation: Developers sometimes add it without fully understanding how screen readers will interpret it. For instance, putting aria-hidden on a logo or nav link effectively removes it from the experience for assistive tech users.
- No real testing: There’s a tendency to assume that if ARIA is present, accessibility is solved. Without testing, it’s easy to miss that it’s actually broken.
The Real Fix: Manual Testing and Developer Discipline

Automated tools are useful for catching low-hanging fruit like missing alt text, color contrast issues, or syntax errors. But they can’t tell you if your ARIA actually works. They’ll detect if aria-expanded is present—but not if it updates correctly when toggled.

Same thing with aria-hidden: they’ll warn you that it’s there, but not if you used it correctly. Maybe the hidden element is decorative (fine) or maybe it’s essential (not fine). Only a human can tell. Most ARIA issues are about behavior and context, which tools can’t judge.

Testing It in the Real World

To know your ARIA implementation works, you’ve got to test it like real users would:
- Keyboard-only navigation: Make sure everything interactive is reachable by tab, focus order makes sense, and keys like Enter, Space, and Arrow keys behave as expected.
- Screen reader testing: Try NVDA on Windows, VoiceOver on macOS, or JAWS if you’re in enterprise. Confirm that roles, labels, and states are being announced correctly—and that hidden content stays hidden without killing important info.
- User testing: If possible, bring in assistive tech users or trained accessibility testers to see how your UI holds up in practice.
Doing this builds confidence that your ARIA-enhanced components are actually usable.

Build a Feedback Loop Into the Dev Process

Accessibility shouldn’t be a post-launch patch job. Bake it into your development flow. Do accessibility checks during code reviews, QA, and design iterations. When you add ARIA, document the behavior you expect, and get feedback from teammates or AT users to verify it works.

Practical Guidelines for Responsible ARIA Use

If you want to use it safely, stick to a few core habits:
- Follow the WAI-ARIA Authoring Practices (APG): They provide vetted patterns and working code examples.
- Use ARIA only when you have to: Lean on semantic HTML first, and treat it as a fallback.
- Test thoroughly: Validate behavior with keyboard and screen readers, not just automated checkers.
- Review aria-hidden usage carefully: Only hide decorative or duplicate content. Never hide focusable items, form controls, or nav links.
- Document your decisions: Leave comments or README notes explaining why it was added and how it’s supposed to work.
- Make accessibility a team effort: It’s not just the job of one dev or QA engineer. Everyone owns it.
ARIA Isn’t a Shortcut—It’s a Responsibility

ARIA is powerful, but it’s not magic. Used carelessly, it creates new barriers and frustrates the very people it’s meant to support. Used deliberately—with a “native first” mindset, real testing, and team buy-in—it can make complex interfaces accessible without breaking usability.

Respect ARIA’s complexity, but don’t fear it. Real accessibility comes from thoughtful use of semantic HTML, strategic ARIA when it’s actually needed, and consistent real-world testing.

If you want to level up your accessibility practices and cut risk, 216digital offers ADA briefings built specifically for dev teams. Schedule one today and start building better, more inclusive code.
Greg McNeil

September 12, 2025

How-to Guides, Legal Compliance

Accessibility, ARIA, keyboard accessibility, WCAG, web developers, web development, Website Accessibility
Shift Happens—But Not On Focus
You press Tab into the first field of a form, and suddenly the page submits. Or you click into a dropdown and, without warning, a new window pops up. Frustrating, right? Now imagine how much more disruptive that is for someone who relies on a screen reader or uses only a keyboard. Sudden shifts don’t just annoy—they break concentration, cause errors, and force users to start over.

That’s the purpose of WCAG’s Success Criterion 3.2.1 On Focus. It makes sure that receiving focus doesn’t trigger unexpected changes. In short: don’t move the user, reload a page, or submit a form just because something got focus. Users should always stay in control.

In this article, we’ll unpack SC 3.2.1, look at common pitfalls, explore best practices, and share testing strategies so your site feels consistent, trustworthy, and usable.

Understanding Success Criterion 3.2.1 – On Focus

The official wording says: When any user interface component receives focus, it does not initiate a change of context.

What this really means is that putting focus on an element—whether by tabbing, shift-tabbing, or clicking—should not be treated as an automatic “go” button.

A change of context includes things like:
- Submitting a form when a field receives focus
- Opening a modal or new window on focus
- Navigating to a new page when a menu item gains focus
- Programmatically moving focus somewhere else the moment you land on an element
This rule is designed to stop those surprises. Changes should only happen when users take action—pressing Enter, clicking a button, or making a choice—not just by landing on something.

Why On Focus Matters

Predictable focus builds trust. Users know where they are, what’s happening, and how to move forward without being thrown off track.

For users with cognitive or visual disabilities, avoiding sudden shifts prevents confusion. For those navigating with a keyboard, a smooth and logical tab order makes it possible to move efficiently through content. Screen readers also benefit from a stable focus path, since consistency allows the technology to announce content clearly. And people with motor impairments are spared the frustration of accidentally triggering submissions or navigations they didn’t intend.

But accessibility isn’t just about a specific group. Predictability benefits everyone. Consistent behavior builds trust and lowers friction, making your site feel polished and respectful of users’ time and effort.

Common Pitfalls (and Why They Break On Focus)

Despite the clear intent of SC 3.2.1, developers often run into familiar traps. A few of the most common include:
- Auto actions on focus: Submitting a form, opening a modal, or swapping pages the instant an input or link gets focus.
- Focus jumps: Using scripts that automatically call element.focus() on load or on focus, dragging the user to an unexpected spot.
- Navigation on focus: Menus that redirect as soon as an item is focused, rather than waiting for activation.
- Broken tab order: Overuse of tabindex—especially with values greater than 0—can create confusing and illogical navigation paths.
- Inconsistent patterns: Mixing models, where some elements act on focus while others require activation, leads to unnecessary confusion.
All of these problems do the same thing: they break user flow, create confusion, and increase errors.

How to Achieve Compliance (and Design a Better Experience)

Preventing these issues comes down to designing focus behavior intentionally and sticking to a few reliable practices.

From there, keep a few best practices in mind:
- Be thoughtful with focus management. If you use element.focus(), do it to genuinely help the user (for example, moving focus into an opened dialog) and respect lifecycle rules.
- Preserve the natural tab order whenever possible. Use tabindex="0" only when necessary to include custom controls, and avoid positive values.
- Be cautious with ARIA. Roles like menu, menuitem, tab, and dialog come with built-in interaction expectations. If you implement them, follow the complete pattern—or stick with native controls.
- Keep patterns consistent. Buttons should submit, links should navigate, and tabs should switch panels only when activated. Uniformity across components builds confidence.
Small details make a big difference. For example, always include a “Skip to main content” link that becomes visible on focus, and ensure it works correctly by pointing to a landmark or an element with tabindex="-1". Likewise, don’t rely on hover or color changes alone to signal interactivity; provide clear focus styles that work for both keyboard and touch users.

Testing Strategies for On Focus

Testing is where theory meets practice. A few methods will quickly reveal whether your site is compliant:

Manual testing
- Tab through every interactive element. Nothing should submit, navigate, or open on focus alone.
- Shift+Tab backward to confirm the reverse path is just as stable.
- Use Enter or Space to activate controls—only then should real actions occur.
- In DevTools, run document.querySelector('#el').focus() and verify that no context change happens.
Assistive Technology Testing

Screen readers like NVDA (Windows) and VoiceOver (macOS/iOS) are essential. Navigate with Tab, rotor, and quick keys to check that focus remains predictable. On mobile, connect an external keyboard and confirm the behavior is consistent with desktop experiences.

Automated Checks

Tools such as Google Lighthouse or WAVE can flag tabindex issues, missing roles, or poor focus order. Automation won’t catch the “surprise factor.” Always back it up with manual and assistive tech testing.

Bad vs. Good: Concrete Examples

Bad: Form Submits on Focus
```
<form action="/submit" method="post">
  <label for="name">Name:</label>
  <input id="name" type="text" onfocus="this.form.submit()">
</form>
```
Issue: The form submits as soon as the field gains focus—a clear violation.

Good: Form Submits Only on Activation
```
<form action="/submit" method="post">
  <label for="name">Name:</label>
  <input id="name" type="text">
  <button type="submit">Submit</button>
</form>
```
Fix: The form submits only when the user explicitly activates the button.

Bad: Navigation on Focus
```
<nav>
  <a href="/pricing" onfocus="window.location=this.href">Pricing</a>
</nav>
```
Good: Navigation Only on Activation
```
<nav>
  <a href="/pricing">Pricing</a>
</nav>
```
Tip: It’s fine to expand a menu on focus for discoverability, but don’t redirect until activation.

Good Example: Custom Control with Predictable Focus
```
<button aria-expanded="false" aria-controls="filters" id="filterToggle">
  Filters
</button>
<div id="filters" hidden>
  
</div>
```
This pattern ensures that nothing happens on focus. Activation (click, Enter, or Space) toggles the state, while ARIA reflects the change.

Frequently Asked Questions

What’s the primary goal of SC 3.2.1 On Focus?
To make sure that receiving focus doesn’t cause unexpected context changes. Users, not scripts, decide when to act.

Is onfocus always forbidden?
Not necessarily. You can use it for subtle cues like highlighting an element. Just don’t trigger navigation, submissions, or new windows.

Can focus ever be moved programmatically?
Yes—if it matches user expectations. For example, moving focus into a modal when it opens, or pointing to an inline error message after a failed form submission, are acceptable.

How should I handle dynamic components like tabs or accordions?
Stick to activation-based behavior. Use arrow keys to move between tabs, but only switch panels when a tab is activated, following WAI-ARIA Authoring Practices.

Build Predictable Experiences (and Trust)

At its core, SC 3.2.1 is about respect. Focus should never feel like a trap door. By preventing context changes on focus, you protect users from confusion, reduce errors, and make your interface feel stable and reliable.

Accessible design isn’t just about checking a box—it builds trust. Predictable interactions show users that their time and attention are valued, whether they’re navigating with a screen reader, a keyboard, or a mouse. And when people can move through your site without fear of surprises, they’re more likely to stay, engage, and return.

If you’re unsure whether your site meets this success criterion—or you’d like expert guidance on weaving accessibility into everyday development—schedule an ADA briefing with 216digital. We’ll review your patterns, coach your team, and help you create consistent, user-friendly experiences that people can rely on.
Greg McNeil

September 8, 2025

How-to Guides, Testing & Remediation

Accessibility, digital accessibility, How-to, keyboard accessibility, On Focus, Web Accessibility, web developers, web development, Website Accessibility
How to Create a Strong Web Accessibility Policy
A web accessibility policy is more than a document—it’s a framework that defines how your organization approaches inclusivity, compliance, and digital responsibility. Without one, accessibility efforts can become inconsistent, reactive, or misunderstood. With one, your team gains a roadmap that builds accountability, supports compliance with laws like the ADA and Section 508, and demonstrates a commitment to all users.

Think of your policy as both a shield and a compass. It protects your organization by showing good-faith effort to regulators, but it also guides your team toward continuous improvement.

Why Your Organization Needs a Policy

Accessibility policies matter for more than just legal defense. Internally, they bring clarity across departments—from IT to marketing to compliance—so everyone understands which standards to follow. They ensure accessibility isn’t dependent on one person’s expertise or limited to a single project cycle.

Externally, a policy builds trust. Customers, investors, and partners see that accessibility is part of your values, not an afterthought. And strategically, accessibility opens doors: people with disabilities and seniors represent nearly half a trillion dollars in disposable income. A policy is a first step toward serving that audience well.

Core Elements of a Strong Web Accessibility Policy

Purpose and Commitment

Begin with a statement of intent. This should be more than a generic declaration; it should connect accessibility to your organization’s mission. For example:

“Our organization is committed to ensuring digital accessibility for all users, including people with disabilities and seniors. We strive to meet or exceed recognized accessibility standards and continuously improve the user experience.”

This opening sets the tone by making accessibility a matter of principle, not just compliance.

Scope

A good web accessibility policy makes it clear what’s covered. Websites are obvious, but often overlooked are mobile apps, intranet systems, PDFs and digital documents, and even third-party platforms like payment processors or video players. By spelling out the scope, you avoid leaving accessibility responsibility in a gray area between departments.

Standards and Guidelines

Policies must be tied to recognized standards. Most organizations point to WCAG 2.1 or 2.2 at Level AA, which is the global baseline. In some cases, ATAG (Authoring Tool Accessibility Guidelines) and UAAG (User Agent Accessibility Guidelines) may also apply, especially if your team develops content management systems or provides custom controls. Referencing these standards prevents vague promises and gives your teams concrete goals.

Accountability

Accessibility only works when responsibilities are clear. Your web accessibility policy should describe who does what—leaders allocate resources, designers and developers build accessible systems, content creators ensure their materials are accessible, and quality assurance checks for compliance. Including procurement teams is especially important, since third-party vendors often introduce accessibility risks.

Testing and Monitoring

Accessibility is not something you achieve once and then check off the list. Your web accessibility policy should outline how accessibility will be tested and monitored over time. Automated scans are helpful but limited; manual testing with screen readers, keyboard navigation, and zooming provides a more accurate picture. Involving people with disabilities in testing is the gold standard. Regular audits—quarterly or annual—should be part of the plan, along with ongoing monitoring through services like a11y.Radar.

Training and Culture

Accessibility knowledge fades without reinforcement. A strong policy requires training for new employees during onboarding, refresher sessions for existing staff, and resources to keep accessibility visible in everyday work. This shifts accessibility from being the job of a few specialists to a shared organizational culture.

Feedback and Grievance Process

Your users need a way to tell you when something isn’t working. Policies should establish a clear feedback mechanism, such as a dedicated email or form, along with expected response times and escalation steps. Done well, this process builds credibility and helps you identify issues before they turn into legal complaints.

Review and Updates

Accessibility standards evolve, and your policy must evolve with them. Commit to reviewing it on a set schedule—at least once a year—and name the role or department responsible for updates. That way, your policy doesn’t quietly drift into irrelevance.

Internal Policy vs. Public Accessibility Statement

One point that’s often misunderstood is the difference between a web accessibility policy and an accessibility statement.

A policy is usually internal, designed to align your staff around roles, standards, and processes. A statement, on the other hand, is public-facing. It communicates your organization’s accessibility efforts, acknowledges areas that may not yet meet standards, and tells users how to get help.

Both are necessary. The internal policy keeps your team aligned, while the public statement demonstrates accountability and transparency to your users. The World Wide Web Consortium (W3C) recommends keeping the internal policy more detailed and technical, while making the statement concise, approachable, and easy to find on your website—often linked in the footer near your Privacy Policy.

Common Pitfalls

Many organizations stumble by making their policies too vague (“we aim to be accessible”) or too ambitious (“we guarantee full compliance at all times”). Others fail to address vendors or neglect to include a way for users to provide feedback. A strong policy balances realism with accountability and leaves no room for ambiguity.

Moving from Policy to Practice

A policy isn’t a box to check—it’s the start of an ongoing process. To put it into practice:
- Integrate accessibility into procurement so third-party tools don’t create barriers.
- Build accessibility into project lifecycles rather than tacking it on at the end.
- Track progress with measurable outcomes, such as reduced accessibility errors in audits.
- Share updates internally and externally to demonstrate that accessibility is a living priority.
Drafted. Signed. Now, Let’s Do This.

A web accessibility policy is more than paperwork. Done well, it declares your commitment, defines your scope, sets standards, assigns responsibility, and ensures accountability through testing, training, and review. By avoiding vague promises and grounding your policy in specific, actionable steps, you give your organization the confidence to serve all users fairly and consistently.

If you’re ready to move from intention to implementation—whether you’re just starting, mid-remediation, or refining a mature program—schedule an ADA briefing with 216digital. In one focused session, our experts will meet you where you are, assess your current posture, and outline a practical, prioritized path toward sustainable web accessibility.

Looking for a place to begin drafting your own policy?

Download our Sample Web Accessibility Policy Template to jumpstart your efforts and adapt it to your organization’s needs.
Greg McNeil

August 27, 2025

How-to Guides

accessibility policy, How-to, Web Accessibility, Website Accessibility
How to Implement Truly Accessible SVG Graphics
SVGs are everywhere—icons, logos, data visualizations, animated illustrations. They’re crisp on any screen, tiny in file size, and easy to style. But here’s the catch: an SVG is only as accessible as you make it. If you don’t give it a name, if you rely on color alone, or if you forget keyboard support, your “perfect” vector can become a roadblock.

This guide gives developers and designers practical steps to build accessible SVG graphics that meet WCAG, work with assistive tech, and still look great.

Understanding SVG Accessibility Fundamentals

SVG (Scalable Vector Graphics) is an XML-based format. Because it’s text-based, you can label it semantically, control it with CSS and JavaScript, and scale it cleanly for magnifiers and high-DPI displays. The benefit? You can transform a standard image into an accessible SVG that supports users with low vision, screen readers, or alternative input devices.

Why SVGs Can Be Great for Accessibility
- Scales cleanly: No blur when a user zooms to 200%+.
- Semantic hooks: You can add <title>, <desc>, and ARIA attributes.
- Keyboard-friendly: With the correct markup, interactive SVGs can be fully operable.
But none of that happens by default. You need to choose the correct pattern and add the right attributes. That’s how you turn a scalable vector into an accessible SVG.

Decorative vs. Informative SVGs: Know the Difference

Decorative SVGs

Remove these visual flourishes (background shapes, dividers) from the accessibility tree so screen readers don’t announce them.
```
<svg aria-hidden="true" focusable="false" width="200" height="50" viewBox="0 0 200 50">
  
</svg>
```
- aria-hidden= "true" hides it from assistive tech.
- focusable= "false" helps older browsers avoid focusing it.
Informative SVGs

These convey meaning (icons that label actions, logos that identify brands, charts that show data). They must have an accessible name and sometimes a longer description.

Common mistakes to avoid:
- No accessible name (the icon is silent to screen readers).
- Meaning conveyed by color only (fails WCAG 1.4.1).
- Interactive graphics that aren’t keyboard operable.
Choosing the Right Pattern: Inline vs. External

Inline SVG (Best for Control and Accessibility)

Inline SVG gives you full control: you can add <title>, <desc>, role, and tie everything together with aria-labelledby.

When to use it: Complex icons, logos with text equivalents, charts, or anything interactive.
```
<svg role="img" aria-labelledby="downloadTitle downloadDesc" viewBox="0 0 24 24">
  <title id="downloadTitle">Download</title>
  <desc id="downloadDesc">Arrow pointing into a tray indicating a download action</desc>
  
</svg>
```
Tip: aria-labelledby lets you explicitly control the accessible name. Screen readers will read the title and then the description when useful.

External SVG via <img src="...">

Use it for simple, non-interactive icons and reusable logos.
```
<img src="/icons/lock.svg" alt="Locked">
```
- Use meaningful alt text.
- If you need a long description (e.g., describing a complex chart), place that adjacent in the DOM and reference it in the surrounding text. You can also wrap the image in a <figure> with a <figcaption> for richer context.
Note: If you rely on <title>/<desc> inside the SVG file itself, those must be authored in the file, not the HTML. You can’t inject them from outside.

Best Practices for Accessible SVGs

Add Accessible Text
- Short label? Use <title> (or alt if using <img>).
- Extra context? Use <desc>, or point to adjacent text with aria-describedby.
```
<figure>
  <svg role="img" aria-labelledby="logoTitle" viewBox="0 0 100 24">
    <title id="logoTitle">Acme Tools logo</title>
    
  </svg>
  <figcaption class="sr-only">Acme Tools, established 1984</figcaption>
</figure>
```
A common pattern for longer descriptions is to reference hidden explanatory text:
```
<p id="chartLongDesc" class="sr-only">
  2025 sales by quarter: Q1 1.2M, Q2 1.5M, Q3 1.4M, Q4 1.8M—Q4 is highest.
</p>
<svg role="img" aria-labelledby="chartTitle" viewBox="0 0 600 400">
  <title id="chartTitle">2025 Sales by Quarter (Bar Chart)</title>
  
</svg>
```
Screen reader–only utility:
```
.sr-only {
  position:absolute !important;
  width:1px;height:1px;
  padding:0;margin:-1px;
  overflow:hidden;clip:rect(0,0,0,0);
  white-space:nowrap;border:0;
}
```
Contrast & Readability

Text inside SVGs follows WCAG text contrast:
- Normal text: 4.5:1 minimum
- Large text (18pt/24px regular or 14pt/18.66px bold): 3:1
- Non-text elements (lines, icons, bars): 3:1 (WCAG 1.4.11).
- Keep text readable at zoom levels users commonly use. Consider vector-effect= "non-scaling-stroke" if thin strokes get too thin when scaled.
Don’t Use Color Alone

Color-only encodings (e.g., red vs. green) aren’t enough. Add:
- Patterns or textures on bars/lines.
- Labels or icons with different shapes.
- Legends with clear text.
```
<pattern id="diagonalHatch" patternUnits="userSpaceOnUse" width="8" height="8">
  <path d="M0,8 l8,-8 M-2,2 l4,-4 M6,10 l4,-4" stroke="currentColor" stroke-width="1"/>
</pattern>
<rect x="10" y="10" width="50" height="200" fill="url(#diagonalHatch)"/>
```
Focus and Keyboard Navigation
- Non-interactive SVGs should not be focusable: tabindex= "-1" and/or focusable= "false".
- Interactive controls should use native HTML elements for the focus/keyboard model. Wrap the SVG in a <button> or <a> rather than adding click handlers to the <svg> itself.
```
<button type="button" aria-pressed="false">
  <svg aria-hidden="true" focusable="false" width="20" height="20">
    
  </svg>
  <span class="sr-only">Mute audio</span>
</button>
```
Provide visible focus styles for WCAG 2.4.7 (e.g., clear outline around the button).

Use ARIA Thoughtfully
- Favor semantics you already get from HTML (<button>, <a>, <figure>, <img>).
- When you do label an inline <svg> as an image, role= "img" plus an accessible name (via <title> or aria-labelledby) is usually enough.
- Avoid piling on roles like graphics-document unless you know the support landscape you’re targeting and have tested it. Over-ARIA can confuse screen readers.
Inherit Color Responsively

For icons that should match text color and adapt to themes, use currentColor:
```
<svg role="img" aria-labelledby="checkTitle" width="20" height="20">
  <title id="checkTitle">Success</title>
  <path d="..." fill="currentColor"/>
</svg>
```
Now your icon inherits color from CSS—great for dark mode.

Sprite Systems (<use>) and Symbols

When using a sprite:
```
<svg class="icon" role="img" aria-labelledby="searchTitle">
  <title id="searchTitle">Search</title>
  <use href="#icon-search"></use>
</svg>
```
Important: Don’t rely on titles inside <symbol>—screen readers often skip them when you reference them with <use>. Add the label at the point of use or wrap the icon in a labeled control.

Testing SVG Accessibility: Don’t Skip This Step

Quick Checklist
- Does the SVG have a clear, accessible name?
- Is extra context available via <desc> or aria-describedby if needed?
- Are decorative elements hidden?
- If interactive: Is it reachable by keyboard? Operable with Enter/Space?
- Is the tab order logical?
- Do text and key shapes meet contrast requirements?
- Do animations honor prefers-reduced-motion?
Tools & Methods
- Screen readers: VoiceOver (macOS/iOS), NVDA or JAWS (Windows), TalkBack (Android).
- Keyboard only: Tab, Shift+Tab, Enter, Space, Arrow keys.
- Zoom to 200% and 400% to check readability and hit target sizes.
Common Pitfalls (and Easy Fixes)

Using SVG as a CSS Background for Meaningful Content

Background images can’t have alt text. If it conveys meaning, embed it inline or with <img> and provide an accessible name.

Forgetting to Label Icons

A lock icon without a label is silent. Add <title> to the <svg> or use <img alt= "Locked">.

Overwriting Contrast With Themes

Dark mode CSS might drop your contrast below 3:1 for shapes or 4.5:1 for text—Re-test after theme changes.

Unlabeled Charts

A beautiful chart that’s unlabeled is unusable. Provide a title, a short summary, and a link or reference to the underlying data table.

Interactive SVG Shapes Without Semantics

Don’t attach click handlers to <path> or <g> and call it done. Wrap the icon in a <button> or <a> and use proper ARIA (e.g., aria-pressed) where appropriate.

Practical Patterns You Can Copy

Informative Standalone Icon (Inline SVG)
```
<svg role="img" aria-labelledby="infoTitle infoDesc" viewBox="0 0 24 24">
  <title id="infoTitle">Information</title>
  <desc id="infoDesc">Circle with a lowercase “i” inside</desc>
  
</svg>
```
Decorative Icon Inside a Button (Button Provides the Name)
```
<button type="button">
  <svg aria-hidden="true" focusable="false" width="20" height="20"></svg>
  Save
</button>
```
Chart With Long Description and Data Table
```
<figure>
  <p id="salesDesc" class="sr-only">
    Bar chart showing quarterly sales for 2025: Q1 1.2M, Q2 1.5M, Q3 1.4M, Q4 1.8M.
  </p>
  <svg role="img" aria-labelledby="salesTitle" viewBox="0 0 640 400">
    <title id="salesTitle">2025 Quarterly Sales</title>
    
  </svg>
  <figcaption>Summary of 2025 sales; see table below for details.</figcaption>
</figure>
<table>
  <caption class="sr-only">Detailed sales data for 2025</caption>
<thead><tr><th>Quarter</th><th>Sales</th></tr></thead>
  <tbody>
    <tr><td>Q1</td><td>$1.2M</td></tr>
    <tr><td>Q2</td><td>$1.5M</td></tr>
    <tr><td>Q3</td><td>$1.4M</td></tr>
    <tr><td>Q4</td><td>$1.8M</td></tr>
  </tbody>
</table>
```
Accessibility for Motion and States

If your SVGs animate, respect user preferences:
```
@media (prefers-reduced-motion: reduce) {
  svg .spin { animation: none; }
}
```
For toggles (like mute/unmute), update both the visual state (icon changes) and the accessible state (aria-pressed, live text updates).

Accessible Design is Intentional Design

Accessible SVGs aren’t just about tags and attributes—they’re about clear communication. When you provide an accessible name, avoid color-only meaning, ensure keyboard operation, and include descriptions where needed, you open your visuals to many more people—without sacrificing design or performance.

Start small and build the habit:
- Label every meaningful icon.
- Hide true decoration.
- Test with a screen reader and the keyboard.
- Re-check contrast after style changes.
Accessibility is a practice, not a checkbox. The pay-off is real: better UX, fewer support issues, and stronger compliance.

Need a Second Set of Eyes?

If you want help reviewing your site’s SVGs, charts, and icon systems, schedule an ADA briefing with 216digital. We’ll give you actionable feedback, prioritize fixes, and help you ship accessible SVG patterns that scale across your design system.
Greg McNeil

August 14, 2025

How-to Guides

Accessibility, accessible code, How-to, SVG, Web Accessibility, web developers, web development, Website Accessibility
Email Accessibility: Make Every Click Count

You spend hours testing subject lines, analyzing open rates, and crafting the perfect call to action. But if your emails are not accessible, you may be unintentionally excluding millions of potential readers. More than one billion people around the world live with some form of disability, and many rely on assistive technologies such as screen readers, magnifiers, or keyboard navigation to interact with digital content. This is why email accessibility should be at the center of every campaign you send.

This is where email accessibility makes a difference. Accessible emails do not only support people with disabilities; they also improve reach, engagement, and usability for everyone. You can think of accessibility as a safety net during your quality assurance process, one that helps make sure your hard work actually reaches its audience. The encouraging part is that small and thoughtful changes can create a big impact.

Structure and Layout: Design for Navigation, Not Just Aesthetics

Attractive design may catch the eye, but structure is what allows readers to move through your message with ease. Using semantic heading tags such as <h1>, <h2>, and <h3> helps organize your content in a way that screen reader users can understand. Headings should flow in a logical order without skipping levels. Relying on bold text or font size alone to show importance does not provide the same clarity.

Tables are another common issue. They should be avoided for layout purposes whenever possible because screen readers can misinterpret them. If a table must be used for structure, adding role="presentation" tells assistive technology that it is decorative rather than data.

It is also important to test your emails using only the Tab key. If you cannot reach every link, button, and input field by tabbing through the message, your subscribers will face the same problem.

Image Accessibility: More Than Just Pretty Pictures

Images are powerful in marketing emails, but without the right preparation, they can create barriers. Every image should include descriptive alt text that explains its purpose. If the image is decorative and does not add meaning, use empty alt text so that screen readers can skip it.

Critical information, such as discount codes or calls to action, should never exist only within an image. Live text ensures that the message still appears even if images are turned off in the inbox. A good test is to disable images and see whether the email still conveys your intended message.

Animations also require care. Flashing or strobing content can cause serious discomfort or even seizures for some readers. Autoplaying GIFs may distract from your main message. Whenever possible, give users the ability to pause or stop moving elements.

Links and Calls to Action: Clear, Clickable, Inclusive

Calls to action are where engagement happens, and they must be designed with clarity in mind. Instead of vague text such as “Click here,” choose phrases like “Read the full guide” or “Shop the new collection.” Screen reader users often move through an email by jumping between links, so each one needs to make sense on its own.

Links should always be visually distinct. Underlining them is the best practice since relying on color alone is not effective for people with color blindness. Buttons and links should also be large enough to tap easily on a mobile device. A minimum size of about 44 by 44 pixels provides enough room for users with limited dexterity. Spacing links apart reduces the chance of misclicks. These adjustments not only improve email accessibility but also increase click-through rates by making the experience smoother for everyone.

Copywriting and Readability: Make Every Word Count

Email accessibility applies to words as much as to code or design. Short and direct sentences help readers understand quickly. Breaking your content into smaller paragraphs with clear subheadings makes the email less overwhelming.

Avoid heavy jargon or insider language that may confuse people. Simple words in everyday language travel further and faster. Writing in an active voice also helps keep your copy engaging.

Do not forget the basics of text styling. Font sizes should be at least 14 points, which is especially important for people with low vision or anyone reading on a small screen. Text should be left-aligned only, since centered or justified alignment slows down reading speed and can reduce comprehension.

Multimedia Content: Do Not Skip the Captions

Many email campaigns now include video, audio, or GIFs. These can make content more dynamic, but they bring accessibility challenges that need attention. Any video or audio clip should come with captions or transcripts. Captions are essential for people who are deaf or hard of hearing, but they also help people who are in noisy environments or those who are somewhere quiet and cannot turn on the sound.

Animated GIFs should avoid flashing sequences or rapid loops. If movement is key to your message, include a description of it in the email copy or offer a static fallback image. Multimedia can be powerful, but it should never come at the expense of accessibility.

A Pre-Send Accessibility Checklist

Before you hit send, it helps to run through a quick accessibility check. Try navigating the email with only your keyboard. Make sure every image includes descriptive alt text or an empty alt attribute if it is decorative. Look at your link text and ask if it clearly describes the action or destination. Turn images off and check if the message still makes sense. Confirm that your color contrast is strong enough to read comfortably. Review your animations to see if they are subtle and under control. Lastly, read the text on both desktop and mobile screens to confirm that the font size is easy to read.

These checks only take a moment, but they can prevent frustration and lost engagement.

Accessibility Is a Long Game, but Every Email Helps

No email will ever be perfectly accessible. The goal is not perfection but progress. Each improvement you make expands your reach, improves engagement, and builds trust with your audience.

Email accessibility is not only about legal compliance. It is also about creating meaningful connections. By removing barriers, you ensure that your message reaches as many people as possible and resonates more deeply with them. Making email accessibility part of your long-term strategy strengthens both your brand reputation and the experience of every subscriber.

The next time you prepare a campaign, add accessibility to your checklist. Treat it as part of your workflow, not an extra chore. An inaccessible email is never as effective as it could be.

If you need a clear plan for accessible digital communication, schedule an ADA briefing with 216digital. We will walk you through practical steps to make your email campaigns and your digital presence more inclusive, more effective, and better prepared for the future.

Greg McNeil

August 12, 2025

How-to Guides, Legal Compliance

Accessibility, email accessibility, WCAG, WCAG Compliance, Website Accessibility
Lost in Focus? Blame Keyboard Traps
You’ve probably been there. You build a custom modal or some fancy dropdown, tab into it to test, and suddenly you’re stuck. Focus won’t move. The Tab key feels broken, Shift+Tab does nothing, and Escape isn’t helping either. That’s not a bug in your laptop—it’s a keyboard trap.

And honestly? They’re way more common than we like to admit. WebAIM has been flagging them as one of the top accessibility failures for over a decade, and the problem hasn’t really improved. The thing is, you don’t need to be an accessibility specialist to fix them. You just need to understand how they occur, how the Web Accessibility Guidelines (WCAG) addresses them, and how to integrate prevention into your regular workflow. Let’s talk through it, developer to developer.

What Are Keyboard Traps?

A keyboard trap happens when focus moves into a component but can’t get back out using standard keyboard navigation. That usually means Tab and Shift+Tab stop working, Escape is ignored, and the user is stuck.

According to WCAG Success Criterion 2.1.2 (“No Keyboard Trap”), any element that takes focus must also provide a way to exit using only the keyboard. In other words: if your widget can grab focus, it must also let go of it.

For developers, this is more than a compliance checkmark. A trap breaks assumptions about how users move through a page. It disrupts assistive tech like screen readers and can fail QA instantly. Even if the rest of your site is clean, one trap in a modal or custom control can undo the entire user journey.

Who’s Affected (And Why You Should Care)

It’s easy to think of accessibility in the abstract, but keyboard traps create very real roadblocks:
- Motor-impaired users rely on the keyboard because a mouse isn’t practical.
- People with temporary injuries—a broken wrist, for example—may need keyboard-only navigation for weeks.
- Screen reader users follow focus to know where they are. If it never moves, the reader has nothing more to say.
- Developers themselves—many of us use the keyboard for speed. If you’ve ever hit Tab to check your own work and gotten stuck, you know how disruptive it feels.
Bottom line: if your component can trap you, it can trap someone who doesn’t have another option.

So where do these traps usually show up? More often than not, in the places where we customize behavior.

Where Keyboard Traps Hide

Traps aren’t usually intentional. They sneak in where custom code overrides native behavior. Here are the usual suspects:

Modals, Popovers, and Dialogs

A modal with div role="dialog" looks great until focus disappears inside. The fix is to intentionally loop focus only while the modal is open and let Escape close it:
```
function trapFocus(modalEl) {
  const focusable = modalEl.querySelectorAll(
    'a[href], button:not([disabled]), input, textarea, select, [tabindex]:not([tabindex="-1"])'
  );
  const first = focusable[0];
  const last = focusable[focusable.length - 1];
  modalEl.addEventListener("keydown", e => {
    if (e.key === "Tab") {
      // If Shift+Tab on first element, wrap back to last
      if (e.shiftKey && document.activeElement === first) {
        e.preventDefault();
        last.focus();
      }
      // If Tab on last element, wrap back to first
      else if (!e.shiftKey && document.activeElement === last) {
        e.preventDefault();
        first.focus();
      }
    } else if (e.key === "Escape") {
      // Allow users to close with Escape and return focus
      closeModal();
    }
  });
}
```
This follows WAI-ARIA practices: focus a meaningful element on open, loop safely, and return focus when closing.

Forms and Custom Inputs

Date pickers or masked inputs often intercept arrow keys, Enter, or Tab. Without an Escape handler, the user is locked. Keep event listeners scoped:
```
datePickerEl.addEventListener("keydown", e => {
  switch (e.key) {
    case "ArrowLeft": /* move date */ break;
    case "ArrowRight": /* move date */ break;
    case "Escape":
      // Escape should always close and release focus
      closeDatePicker();
      break;
    default:
      return; // Don’t block Tab or Shift+Tab
  }
});
```
Also keep aria-expanded updated so assistive tech knows when a picker is open or closed.

Media Players

Custom video players sometimes swallow every keydown. Space, arrows, and Tab all get blocked. That’s a recipe for keyboard traps. Instead:
```
playerEl.addEventListener("keydown", e => {
  if (e.key === " " || e.key.startsWith("Arrow")) {
    // Map keys to playback controls (play, pause, seek, etc.)
    e.stopPropagation(); // Stop event bubbling, but don’t block Tab
  }
  // Important: Don’t block Tab!
});
```
For YouTube iframes, use ?disablekb=1 to disable its shortcuts and implement your own accessible ones.

JavaScript-Enhanced Links

Sometimes developers add keydown handlers to links or buttons that override Tab. If you call preventDefault() on Tab, you’ve created a trap.

Rule of thumb: only intercept Space or Enter for activation. Let Tab do its job.

Testing for Keyboard Traps

Automation tools like WAVE or Lighthouse can catch some violations, but many traps slip through. Manual checks are essential:
- Start at the browser address bar.
- Press Tab repeatedly.
- Watch the focus ring. Does it keep moving or stall?
- Use Shift+Tab to go backward.
- Open components like modals, menus, or players. Try Escape. Does it close and return focus?
Build this into your QA flow. Think of it as a “keyboard-only smoke test.” It takes two minutes and can save your users hours of frustration.

Best Practices for Trap-Safe Code

To keep keyboard traps out of your codebase:
- Use native elements whenever possible—buttons, links, selects. They come with keyboard behavior for free.
- Follow ARIA Authoring Practices when building custom components. They define expected key behavior for dialogs, menus, and more.
- Centralize focus-trap utilities. Don’t reinvent it in every modal.
- Document the behavior. A hint like “Press Escape to close” in a dialog helps everyone.
- Add accessibility checks in your Storybook or Cypress tests. Press Tab in your stories. Does it cycle correctly?
A Safe Dropdown in Action

Here’s a minimal example of a dropdown that avoids keyboard traps:
```
<button id="dropdown-trigger" aria-expanded="false" aria-controls="dropdown-menu">
  Options
</button>
<ul id="dropdown-menu" role="menu" hidden>
  <li role="menuitem"><a href="#">Profile</a></li>
  <li role="menuitem"><a href="#">Settings</a></li>
  <li role="menuitem"><a href="#">Logout</a></li>
</ul>
```
With the right ARIA attributes and by leaving Tab behavior untouched, this dropdown stays safe and accessible.

Build Trap Prevention into Your Workflow

Don’t treat accessibility like a last-minute patch. Bake it into your process:
- Add “keyboard-only test” to your pull request checklist.
- Run axe-core or similar tools on staging builds.
- Train QA and PMs to check focus flows during reviews.
- Pair with design: ask early, “How would this work without a mouse?”
These habits don’t just prevent keyboard traps—they build a culture of inclusive development.

Focus on What Matters

Accessibility slips often come from the smallest details—like a single missing Escape handler or an overzealous preventDefault(). But those little choices ripple out into real-world barriers. The upside is, once you start looking for them, traps are one of the easiest things to fix—and the payoff is huge.

If you’re looking to strengthen your accessibility practices and reduce risk, 216digital offers ADA briefings tailored specifically for development teams. These sessions go beyond checklists—they walk through real code examples, explain how WCAG applies in day-to-day work, and give your team a clear roadmap for building components that won’t leave users stuck. It’s a chance to ask questions, get practical guidance, and bring accessibility into your workflow in a way that lasts.

Schedule an ADA briefing today and start building better, more inclusive code.
Greg McNeil

August 4, 2025

How-to Guides

Accessibility, How-to, keyboard accessibility, Keyboard Navigation, Keyboard traps, web developers, web development, Website Accessibility

Accessible Infographics? You’ve Got This

We’ve all shared or pinned a gorgeous infographic only to discover later that it’s unreadable on a phone or impossible for a screen reader to explain. That disconnect can leave a big slice of your audience—people who rely on assistive tech, low‑vision users, mobile users, and anybody skimming—out of the story you worked hard to tell. The good news? You don’t have to pick between visual flair and inclusivity. A handful of WCAG‑inspired habits will let your next infographic sparkle and speak to everyone. Accessible infographics make that possible—balancing form, function, and inclusivity without sacrificing design.

Why Accessibility in Infographics Matters

It’s the right thing and the smart thing. Legal compliance matters, but so does brand trust. Inclusive visuals show you value every visitor without using scare tactics.
Wider reach. Alt text, transcripts, and high‑contrast design remove barriers for millions of people with disabilities—and for situational limitations like glare or slow bandwidth.
Mobile muscle. Clean, well‑structured graphics load faster and resize gracefully.
SEO & UX boost. Search engines can’t “see” pictures, but they can read your text equivalents, giving your infographic a discoverability edge.

Think of accessibility as a design constraint that ignites creativity, not a brake pedal. Accessible infographics prove that good design and good access can go hand-in-hand.

Core Principles for Accessible Infographic Design

1. Start With Simplicity

Simple visuals land harder and translate better.

Stick to 5–7 key takeaways—enough to inform, not overwhelm.
Trim decorative flourishes that don’t support the story.
Let white space breathe so eyes can rest and elements stand out.

2. Organize With a Logical Structure

Viewers should follow your flow without guessing.

Group related data in clear clusters or panels.
Use subtle borders or tinted backgrounds to separate sections.
Keep a steady top‑to‑bottom, left‑to‑right reading order. If you must break it, guide with numbered steps or arrows.

3. Prioritize Readable Text

Fancy fonts may look slick, but legibility rules.

Do	Skip
Sans‑serif faces like Arial, Verdana, Open Sans	Ornate scripts or heavy italics
14 pt minimum (roughly 18–20 px on web)	Tiny captions that force zooming
Sentence case	ALL CAPS everywhere
Horizontal text	Diagonal or curved text

Even sighted readers appreciate the clarity—especially on smaller screens.

Make the Visuals Understandable to Everyone

4. Provide Text Equivalents

Alt text isn’t just for photos.

Basic shapes or icons: “Pie chart showing 60 % of users prefer mobile.”
Complex data: Add a long description or transcript nearby or in a collapsible section—describe axes, color keys, and trends.
Link out if the description is lengthy (great for dashboards).
Sprinkle in ARIA roles (role= "img") sparingly when embedding the graphic inside interactive layouts.

The rule of thumb: If someone couldn’t see the image, would your text give them the same insights? This step is at the heart of what makes accessible infographics work for everyone—not just some.

5. Use Color With Care

Color is an accent, not a crutch.

Keep a 4.5 : 1 contrast ratio for text and meaningful icons. Online checkers like WebAIM make it fast.
Pair hues with patterns, labels, or icons so color‑blind users still get the message. Think stripes vs. solids on a bar chart.
Limit yourself to 3–5 colors plus neutrals. A restrained palette keeps focus where it belongs—your data.

Good color contrast is essential to creating accessible infographics that everyone can interpret accurately.

Don’t Forget the Tech‑Specific Details

6. Accessible Animation (If You Use It)

Micro‑animations can bring data to life—but keep them optional.

Avoid flashes faster than three times per second.
Provide pause/stop controls or opt-out settings.
Offer a static fallback (SVG or PNG) so no one gets stuck waiting on motion.

7. Link Design

Infographics often point to reports or landing pages.

Target size: At least 24 × 24 px so thumbs and keyboards can hit comfortably.
Make the link text explain itself: “Download Full Report” beats “Click Here.”
Style hover, focus, and visited states so users always know where they are.

8. Optimize for Mobile

Over half of your audience views on small screens first.

Create a responsive layout that re‑flows vertically.
Test touch targets with your own hands—thumb‑stretch included.
Use SVG or responsive HTML/CSS infographics to scale without blur.

Responsive design ensures accessible infographics display clearly and consistently no matter what device someone is using.

Test Like Accessibility Depends on It (Because It Does)

Automated checks
- WAVE browser extension for structure issues.
- WebAIM Contrast Checker for color ratios.
Manual passes
- Screen reader skim (NVDA or JAWS on Windows, VoiceOver on Mac/iOS).
- Keyboard‑only navigation—can you tab through links and controls?
- Real‑world mobile test—rotate, zoom, and scroll.
User feedback
Nothing replaces insight from people with disabilities. If possible, include them in your review cycle.
Need deeper assurance? A third‑party accessibility audit can spotlight hidden gaps before launch.

Accessibility Isn’t a Compromise—It’s a Design Strength

Accessible infographics amplify your reach, polish your user experience, and future‑proof your brand. Yes, the checklist feels long at first—but each small win builds momentum. Before you know it, designing with inclusion in mind becomes second nature, and your visuals resonate with everyone.

Want a shortcut to confidence? 216digital specializes in turning creative ideas into accessible infographics without draining your team’s bandwidth. Schedule a personalized ADA briefing, and we’ll walk you through what matters most for your brand, your users, and your workflow.

Inclusive storytelling isn’t beyond your skill set—you’ve got this.

Greg McNeil

July 29, 2025

How-to Guides

Accessibility, Accessible Design, infographic, Web Accessibility, Web Accessible Design, Website Accessibility

UX in Mind: Your Simple Guide to Accessible Design
The success of any website or app really boils down to one thing: how it feels to use. If people can navigate your site easily, find what they’re looking for, and get things done without frustration, they’re far more likely to stick around—and come back. But when the experience is confusing, clunky, or leaves some users behind? That’s when you lose them.

At its core, good UX design is about making sure everyone can use your product—regardless of ability, device, or familiarity. The best experiences don’t just work for some; they work for all.

We’ve put together a practical checklist to help you design with accessibility in mind—covering visual, auditory, motor, and cognitive needs. And we’ll point you toward helpful tools and resources so you can keep learning, keep improving, and keep building digital experiences that truly welcome everyone.

The Fundamentals of Accessible UX

Accessibility is about designing for how people actually live and interact—not just for some perfect, idealized user. It’s about making space for the full range of human experiences, because that’s who’s showing up at your digital doorstep. And when you zoom out, the impact becomes clear: over 16% of the world’s population lives with a significant disability. When you keep that in mind from the start, the end result isn’t just more inclusive—it’s better for everyone.

And yes, the benefits are very real:
- You’ll reach more people
- Build stronger trust with your audience
- Lower your legal risks
- And create a smoother, more enjoyable experience across the board
But to get there, it helps to understand how accessibility and usability work together.

Accessibility vs. Usability

Accessibility and usability go hand in hand, but they aren’t quite the same thing. Accessibility means people can use your site—regardless of ability. Usability means they want to. It’s the difference between building a ramp and making sure the door is easy to open once you get there. When both are in place, you’re not just meeting a requirement—you’re delivering a great experience.

So how do you do that in practice?

In the sections ahead, we’ll walk through four key areas to focus on: visual, auditory, motor, and cognitive accessibility. Each one connects to the WCAG POUR principles—Perceivable, Operable, Understandable, and Robust—which are all about making digital content work well for as many people as possible, in as many ways as possible.

Visual Accessibility: Making Your Content Clear

When it comes to digital experiences, what people see—and how clearly they see it—matters. Strong accessible design means your content shows up well for everyone, no matter their vision or viewing environment. Whether someone’s using a screen reader, navigating with magnification tools, or just scrolling on their phone in the sun, your design choices can make a big difference.

Color and Contrast: Give Every Element a Voice

Color does a lot of heavy lifting in design, but it shouldn’t have to carry meaning on its own. Good contrast helps your content stand out and stay legible in all kinds of settings—from dark rooms to bright sidewalks. Use tools like WebAIM Contrast Checker to spot trouble areas before your users do.

Instead of just using red to show an error, pair it with an icon and a message that says what’s going on. That way, everyone—regardless of how they see color—gets the same info. And skip putting important text over photos or gradients. It might look nice, but it often makes things harder to read.

Try this: View your layout in grayscale. Can you still tell what’s what? If not, it’s time for a few tweaks.

Text and Typography: Keep It Clean and Comfortable

Fonts don’t just carry words—they carry the experience. Stick with simple, sans-serif fonts like Arial, Helvetica, or Open Sans. They’re easier to read and less likely to cause eye strain. Avoid fancy decorative fonts for body copy, and go with a minimum of 16px for body text. Line height should feel breathable—somewhere around 1.4 to 1.6x the font size—so your words don’t feel cramped.

And remember, people should be able to zoom in up to 200% without a loss of content. That’s not just a nice-to-have—it’s part of WCAG’s requirements.

Quick test: Zoom way in and try navigating with just a keyboard. Everything should still be readable, usable, and scroll in one direction.

Images and Media: Describe What Matters

Images aren’t just decoration—they carry meaning, emotion, and context. But that only works if everyone gets to experience them. That’s where alt text comes in. For each image, ask yourself: What is this doing here?

If it’s decorative, mark it with empty alt text (alt=""). If it’s showing something important—like a process, a chart, or an instruction—give it a short, clear description. And for complex visuals? Offer a more detailed breakdown nearby or link out to a longer description.

Heads up: Avoid embedding key text inside images. If you have to, make sure that the same info is also available as live text on the page.

Links and Structure: Build a Clear Path

“Click here” doesn’t cut it anymore. Link text should be clear and specific—like “Download the full pricing guide” or “View shipping options.” This gives screen reader users meaningful context and helps anyone scanning your page understand exactly where a link will take them.

But clarity isn’t just about links—it’s about how the entire page is structured.

Use semantic headings (H1 to H6) to create a strong, logical outline. That helps screen reader users and keyboard navigators alike. And if you want to go a step further, use ARIA landmarks (like role= "main" or role= "navigation") to give even more structure to your layout.

Try this: Tab through your site or listen to it with a screen reader. If the page sounds confusing out loud, it probably reads that way too.

Auditory Accessibility: Sound That Speaks to Everyone

Audio can bring depth to your content—but only if it’s accessible. Make sure all multimedia includes captions or transcripts. This isn’t just about supporting users who are d/Deaf or hard of hearing—it’s about meeting people where they are: whether they’re in a crowded café, a quiet office, or scrolling with the sound off.

Captions should be accurate, well-timed, and include important background sounds like [music] or [laughter] when they add meaning. Bonus points if you also let users control playback speed, jump to specific moments, or pause when needed.

Skip the surprise: Don’t autoplay audio or video. And if it starts automatically, make sure there’s an easy-to-find pause or mute button.

If your design relies on voice commands, always offer another way to engage—like buttons, text input, or keyboard shortcuts. Voice should be an option, not a barrier.

Motor Accessibility: Let Everyone Navigate Their Way

Not everyone uses a mouse. For some users, navigating your site with a keyboard—or assistive tools like switch controls—is their primary method. That’s why motor accessibility is so important.

Your site should be fully usable with just a keyboard. That means:
- A logical tab order that follows the flow of the page
- Visible focus styles that clearly show where the user is
- Accessible modals that keep focus inside until they’re closed
- A skip link to let users jump past repeated content
Touch targets need to be big enough—at least 44px by 44px—and spaced well so people don’t hit the wrong button by accident. And don’t rely on hover-only tooltips. Make sure the same info shows up when elements get keyboard focus or a tap.

Test it out: Try using your site with only the keyboard. You’ll quickly spot any dead ends or frustrating traps.

Cognitive Accessibility: Make It Clear, Make It Work

Cognitive accessibility is about reducing mental strain. It’s for users who may be neurodivergent, have memory or learning differences, or just want a simpler, calmer experience (which, honestly, is all of us sometimes).

Consistency is key. Stick with familiar UI patterns and avoid switching up layouts too often. Too many options on one page? That can be overwhelming. Break things down. Keep it focused.

Tips that go a long way:
- Use plain, conversational language
- Break content into bite-size chunks
- Add helper text or examples near form fields
- Use bullet points and clear headers to help users scan
Avoid flashy carousels, blinking elements, or countdown timers that can’t be paused. If a timer is necessary—say for a session timeout—give users a heads-up and a way to extend their time.

Pro move: Offer a simplified or “reading mode” view for content-heavy pages. It can make a big difference in comprehension and comfort. These types of accessible design choices often benefit all users, not just those with cognitive disabilities.

Accessible Design Checklist

Keep this quick-reference checklist close at hand:

▪ Strong color contrast (4.5:1 minimum)

▪ No reliance on color alone for important information

▪ Legible, scalable fonts and adequate spacing

▪ Descriptive alt text for images

▪ Clear, descriptive link text

▪ Proper heading structure (H1–H6)

▪ Keyboard navigable with logical tab order

▪ Captions and transcripts for all multimedia

▪ Accessible media playback controls

▪ Large, spaced interactive elements

▪ Consistent layout and navigation

▪ Plain language instructions

▪ Flexible time limits for tasks and forms

Accessible Design Never Clocks Out

You’re already doing the work—asking better questions, designing more thoughtfully, and looking at your site through more than one lens. That’s what leads to lasting change.

There’s no final destination when it comes to accessible design. But every shift in your design process—every adjustment, every decision made with someone else’s experience in mind—moves the web in the right direction.

And if you ever want backup or a fresh set of eyes, 216digital is here to help. We offer accessibility briefings to give you clarity, confidence, and a plan to move forward.
Greg McNeil

July 24, 2025

How-to Guides

Accessibility, Accessible Design, Graphic Designer, How-to, inclusive desgin, UX, WCAG, Web Accessibility, Web Accessible Design
Like, Share, Include: Social Media Accessibility
Social media is where we show up—for birthdays, announcements, encouragement, jokes, check-ins, and every little update in between. It’s where we stay connected to the people and communities that matter to us.

But what happens when someone can’t fully experience that connection because of how a post was made?

If your content isn’t accessible, you could be leaving people out—often without realizing it. And we’re not just talking about small numbers. Over a billion people worldwide live with some form of disability. Millions of users on social platforms are trying to engage just like anyone else every day.

Social media accessibility is about noticing those barriers and learning how to remove them. The changes you need to make aren’t overwhelming. In fact, they’re surprisingly simple. With just a few thoughtful tweaks, your posts can reach more people, read more clearly, and connect more deeply. Let’s break it down together.

Speak Clearly: Write for Real People

Most of us scroll fast, scan quickly, and move on. So let’s keep things simple—for everyone.
- Use everyday language. Aim for short, clear sentences that sound like how people actually talk. It helps readers and screen reader users alike.
- Capitalize your hashtags. Writing them in #camelCase or #PascalCase (like this: #SocialMediaMatters) helps screen readers pronounce the words correctly.
- Go easy on the emojis. A heart here and there? Great. But avoid long emoji strings, and always place them at the end of a sentence so they don’t disrupt the flow.
- Skip formatting tricks. Don’t use dots, dashes, or weird spacing to line up your text. It may look cute visually, but it makes a mess for screen readers and mobile users.
- Use meaningful links. “Click here” doesn’t tell someone what they’re about to open. Try something like “See our full video recap” instead.
These small writing changes are one of the easiest ways to improve social media accessibility without altering your brand’s voice.

Make Your Visuals Speak—To Everyone

Photos, memes, and infographics carry so much meaning in a post—but only if people can access them. Here’s how to make your visuals work for all users.
- Add alt text to all images. Skip phrases like “image of” and go straight to the point: what’s important in the picture?
- Check your contrast. Text over images or colored backgrounds should meet at least a 4.5:1 contrast ratio. This makes sure everyone—including those with low vision—can read it.
- Avoid putting text inside images. If you do, repeat that text in the caption or alt text.
- Use GIFs with caution. Make sure they’re slow-looping and avoid flickering, which can trigger seizures or migraines.
Caption Everything: Videos and Audio

Whether it’s a behind-the-scenes clip, a podcast preview, or a quick update from your phone, make sure your media includes everyone.
- Always include captions for videos. Even auto-generated ones need human editing to fix errors and add sound context.
- Include transcripts for longer audio or video content like interviews or behind-the-scenes clips.
- Write short video descriptions. These help users understand the purpose or story of the video before they watch.
- Avoid flashy content. Anything that flashes more than 3 times per second could be dangerous. Keep it slow and simple.
- Let users control playback. Don’t autoplay media. Give people the power to start and stop it on their own.
Your Pre-Post Accessibility Checklist

Before you tap “share,” take 30 seconds to run through this:
- Is the writing clear, casual, and easy to follow?
- Are your hashtags capitalized properly?
- Did you add alt text or a description for every image or video?
- Are emojis minimal and placed at the end?
- Do your links say what they lead to?
- Did you check your text/background contrast?
- Are captions accurate and reviewed?
- No autoplay or flashing content?
Running this quick check every time is a great habit to support consistent social media accessibility across all your posts.

Why It’s Worth It

Making your posts accessible isn’t just about compliance—it’s about connection. When more people can engage, more people feel seen. And that leads to better conversations, stronger communities, and yes—better performance, too.
- You’ll reach more people. Simple as that. Accessible posts invite more users in.
- Try it yourself. Use VoiceOver (on iPhones) or TalkBack (on Android) to hear how your post sounds to a screen reader.
- Watch the metrics. Posts with solid alt text, good contrast, and proper captions often get more clicks, longer watch times, and stronger engagement.
Free Tools to Help You Out

No need to figure it all out alone. These tools make social media accessibility easier:
- Contrast Checkers: WebAIM, Accessible Colors,
- Caption Helpers: YouTube Studio (for editing auto-captions)
- Assistive Testing: VoiceOver (iOS), TalkBack (Android), NVDA (PC)
- Accessibility Guidelines: WCAG 2.1 or 2.2
Social Media Accessibility Is About People, Not Just Posts

Accessibility isn’t about being perfect—it’s about being aware. Social media accessibility helps make sure the stories you share, the moments you celebrate, and the content you create are open to everyone who wants to be part of it.

It shows you care. It builds trust. And it reflects the kind of brand or team that people want to follow.

Want to take it a step further? Before your next campaign, schedule an ADA briefing with 216digital. We’ll help you build inclusive strategies that work—for everyone.
Greg McNeil

July 18, 2025

How-to Guides

Accessibility, social media, social media accessibility, Web Accessibility, Website Accessibility
Accessible Websites Start with Universal Design
Last month, a prospect called us—stressed and uncertain. A customer had tried to make a purchase on their site but couldn’t complete it. The text was too light, the font too small, and there was no way to navigate using a keyboard. That one interaction ended in frustration—for the customer, and now, possibly, legal trouble for the business.

It’s a familiar pattern. Whether it’s blurry buttons, unlabeled images, or missing alt text, we see the same barriers show up again and again. And while meeting Web Content Accessibility Guidelines (WCAG) is essential, accessibility can’t just be a checklist item.

What if we reimagined the foundation of how we build—starting not with minimum compliance, but with inclusion at the core? That’s the promise of universal design: a human-first approach that considers every user from the very first wireframe.

Let’s look at how this mindset shift can reshape your process—and your outcomes—for the better.

From WCAG to Universal Design

We owe a lot to WCAG. It gives us a clear framework—a shared language to measure accessibility. But while it tells us what needs fixing, it doesn’t always guide us on how to design better in the first place.

That’s where universal design comes in. Originally coined by architect Ronald Mace, this approach was about creating physical environments usable by everyone, regardless of ability. That philosophy translates beautifully to digital spaces. Instead of retrofitting accessibility after launch, universal design asks us to include everyone from the first wireframe.

Think of it as a shift in mindset: from compliance checklists to inclusive thinking. Because real accessibility doesn’t begin with a requirement. It begins with a question—who are we leaving out, and how can we bring them in?

The Seven Principles of Universal Design (for the Web)

Let’s explore how the core principles of universal design apply online—and how you can weave them into your next build.

1. Equitable Use

Everyone should be able to access the same content, no matter how they browse.
- Add descriptive alt text to images.
- Make sure every action can be done with a keyboard.
- Keep layouts and functionality consistent across devices and assistive tech.
Quick tip: Don’t rely on color alone to convey success or errors. Pair it with icons or text for clarity.

2. Flexibility in Use

Design for choice. People interact with websites in a variety of ways—and your site should support that.
- Let users resize text or adjust fonts.
- Avoid autoplay on videos or audio—give control back to the user.
- Offer simplified views or “reader mode” toggles.
Bonus idea: A dark mode toggle isn’t just stylish. It improves comfort for people with light sensitivity or visual fatigue.

3. Simple and Intuitive Use

People shouldn’t need a manual to navigate your site.
- Stick to recognizable interface patterns.
- Write in clear, conversational language.
- Label buttons and links with purpose.
Helpful tip: Avoid vague CTAs like “Click here.” Instead, try “View pricing” or “Download our guide.” Clarity helps everyone.

4. Perceptible Information

Not everyone perceives content the same way. Support multiple senses.
- Use proper headings and labels to structure your content.
- Add captions to videos and transcripts to audio.
- Apply ARIA labels where appropriate for screen readers.
Pro tip: Run a color contrast check and test your design using tools like WAVE or axe. Small changes here make a big difference for low-vision users.

5. Tolerance for Error

Mistakes happen. Your design should help people recover—not punish them for slipping up.
- Offer undo buttons or confirmations before critical actions.
- Make error messages clear and instructive—not vague.
- Delay dropdowns slightly to prevent accidental clicks.
Extra guidance: Build gentle, guiding error states. Instead of a red wall of text, offer solutions that help users fix the issue.

6. Low Physical Effort

Navigation shouldn’t feel like a workout.
- Use large tap targets for buttons and links.
- Minimize the number of steps in a process or form.
- Ensure full keyboard navigability.
Workflow tip: Try navigating your site using only the tab key. Can you reach everything? Can you do it comfortably?

7. Appropriate Size and Space for Use

Your content should work beautifully across all devices, zoom levels, and tech setups.
- Design responsively for screens big and small.
- Keep enough space between buttons and elements.
- Test at 200% zoom and with screen magnification tools.
Don’t forget: Modals and dropdowns should stay accessible and functional—even when zoomed in or viewed on assistive devices.

A Quick Universal Design Checklist

Here’s a snapshot to keep top-of-mind as you build:
- Use high-contrast colors
- Make all functionality keyboard accessible
- Avoid autoplay; allow user control
- Use meaningful labels and headings
- Provide multiple content formats (text, audio, video)
- Simplify interactions (shorter forms, fewer clicks)
- Test using screen readers and magnifiers
These aren’t just “nice-to-haves.” They’re smart, scalable practices that lead to better design—for everyone.

The Real-World Impact of Universal Design

Designing for inclusion doesn’t just support people with permanent disabilities—it supports all users in the moments they need it most.

Think about:
- An older adult struggling with small fonts
- Someone navigating one-handed while holding a baby
- A person recovering from surgery using voice controls
- A traveler on slow Wi-Fi trying to load your homepage
Inclusive design shows up for all of them. And the benefits ripple outward. Research shows that universally designed sites can reach up to four times the audience, reduce legal risk, strengthen SEO, and build stronger brand loyalty.

This isn’t just about ethics or empathy (though both matter). It’s about resilience. It’s about reach. And yes—it’s about results.

Bringing Universal Design into Your Workflow

You don’t need to start over. You just need to start intentionally.
- Begin with inclusion at the wireframe stage.
- Add accessibility tasks to your backlog from day one.
- Use tools like Google Lighthouse, WAVE, and screen reader emulators.
- Test with people, not just automation.
- Share wins with your team—accessibility is a team sport.
It doesn’t have to be perfect on the first try. Universal design is a practice, not a finish line. Keep improving, keep learning—and keep centering people.

Start with People. Build with Purpose.

Universal design isn’t just for people with disabilities—it’s for everyone. It’s about recognizing that good design serves more than a use case; it serves a human being.

As developers and designers, we have the opportunity—and responsibility—to create digital spaces that welcome, support, and include. When we approach our work with empathy and intention, we move beyond compliance. We build experiences that work better for everyone.

If you’re ready to design with that mindset—whether you’re refining what exists or starting fresh—we’re here to help.

Schedule an ADA briefing with 216digital, and let’s make accessibility part of your foundation—not just a fix.
Greg McNeil

July 15, 2025

How-to Guides

Accessibility, Accessible Design, How-to, Universal design, Web Accessible Design, Website Accessibility

What ARIA Is—and What It’s Supposed to Do

When Is It Necessary?

Why It Shouldn’t Be the Default Tool

Common ARIA Misuse That Breaks Accessibility

Why ARIA Usage Correlates with More Errors

The Real Fix: Manual Testing and Developer Discipline

Testing It in the Real World

Build a Feedback Loop Into the Dev Process

Practical Guidelines for Responsible ARIA Use

ARIA Isn’t a Shortcut—It’s a Responsibility

Understanding Success Criterion 3.2.1 – On Focus

Why On Focus Matters

Common Pitfalls (and Why They Break On Focus)

How to Achieve Compliance (and Design a Better Experience)

Testing Strategies for On Focus

Manual testing

Assistive Technology Testing

Automated Checks

Bad vs. Good: Concrete Examples

Bad: Form Submits on Focus

Good: Form Submits Only on Activation

Bad: Navigation on Focus

Good: Navigation Only on Activation

Good Example: Custom Control with Predictable Focus

Frequently Asked Questions

Build Predictable Experiences (and Trust)

Why Your Organization Needs a Policy

Core Elements of a Strong Web Accessibility Policy

Purpose and Commitment

Scope

Standards and Guidelines

Accountability

Testing and Monitoring

Training and Culture

Feedback and Grievance Process

Review and Updates

Internal Policy vs. Public Accessibility Statement

Common Pitfalls

Moving from Policy to Practice

Drafted. Signed. Now, Let’s Do This.

Understanding SVG Accessibility Fundamentals

Why SVGs Can Be Great for Accessibility

Decorative vs. Informative SVGs: Know the Difference

Decorative SVGs

Informative SVGs

Choosing the Right Pattern: Inline vs. External

Inline SVG (Best for Control and Accessibility)

External SVG via <img src="...">

Best Practices for Accessible SVGs

Add Accessible Text

Contrast & Readability

Don’t Use Color Alone

Focus and Keyboard Navigation

Use ARIA Thoughtfully

Inherit Color Responsively

Sprite Systems (<use>) and Symbols

Testing SVG Accessibility: Don’t Skip This Step

Quick Checklist

Tools & Methods

Common Pitfalls (and Easy Fixes)

Using SVG as a CSS Background for Meaningful Content

Forgetting to Label Icons

Overwriting Contrast With Themes

Unlabeled Charts

Interactive SVG Shapes Without Semantics

Practical Patterns You Can Copy

Informative Standalone Icon (Inline SVG)

Decorative Icon Inside a Button (Button Provides the Name)

Chart With Long Description and Data Table

Accessibility for Motion and States

Accessible Design is Intentional Design

Need a Second Set of Eyes?

Structure and Layout: Design for Navigation, Not Just Aesthetics

Image Accessibility: More Than Just Pretty Pictures

Links and Calls to Action: Clear, Clickable, Inclusive

Copywriting and Readability: Make Every Word Count

Multimedia Content: Do Not Skip the Captions

A Pre-Send Accessibility Checklist

Accessibility Is a Long Game, but Every Email Helps

What Are Keyboard Traps?

External SVG via `<img src="...">`

Sprite Systems (`<use>`) and Symbols