How-to Guides Archives/Category

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
How to Design Accessible Icons that Users Love
Icons are everywhere—on mobile apps, websites, dashboards, and devices. They’re small, but they do big things. Icons help us find a menu, delete a file, or save something for later. Designers love them for good reason: they’re stylish, space-saving, and often universal. But here’s the question—are they really accessible to everyone?

It’s easy to focus on how icons look, but what about how they function for people using screen readers, people with low vision, or anyone who relies on keyboard navigation? In this article, we’ll take a closer look at the benefits and challenges of using icons, the common accessibility mistakes, and the steps designers and developers can take to create accessible icons that improve user experience without sacrificing style.

Why Icons Matter (Beyond Aesthetics)

Well-designed icons help users make sense of content faster. According to research aligned with WCAG guidance, familiar icons can support users with reading or cognitive challenges by serving as helpful visual cues. A simple “trash can” icon can quickly signal delete. A “magnifying glass” screams search. When paired with labels, these accessible icons create a faster and clearer experience for all users.

Saving Space on Smaller Screens

Icons also shine when space is tight—especially on mobile. Instead of cramming menus or actions into text links, icons can simplify the interface and reduce visual clutter. When used thoughtfully, accessible icons help you keep things clean while making the site easier to use.

Common Accessibility Challenges with Icons

Ambiguity: One Icon, Many Meanings

Icons aren’t always as clear as we think. A heart icon might mean “like,” “save,” or “favorite.” Without proper labeling, users may misinterpret its purpose. WCAG requires that all non-text elements, including icons, have text alternatives that clearly explain what they do. Accessible icons must carry meaning that’s clear—both visually and programmatically.

Decorative Icons That Get in the Way

Not every icon needs to be “read.” Some are purely decorative—like flourishes in a logo or background design. But if these aren’t properly hidden from screen readers, they add clutter and confusion. WCAG recommends using aria-hidden= "true" or similar methods to hide decorative icons. That way, screen reader users don’t have to sift through unnecessary details.

Size, Contrast, and Clickability

Icons that are too small or faint are hard to see or click—especially for users with motor or vision challenges. WCAG suggests a touch target size of at least 44×44 pixels. Icons should also meet contrast guidelines (at least a 3:1 ratio against the background). And if someone’s using a keyboard to navigate, your icons must have clear focus indicators and be easy to tab to.

Best Practices for Creating Accessible Icons

1. Label Every Interactive Icon

Icons that do something—like opening a menu or submitting a form—need a clear label. You can add a visible text label, a hidden <span> for screen readers, or an aria-label attribute. For example:
```
<button aria-label= "Open menu">
  <svg aria-hidden="true" width="24" height="24" role="img">
    
  </svg>
</button>
```
This makes sure your accessible icons work for both sighted and non-sighted users.

2. Hide Decorative Icons Properly

If an icon doesn’t add meaning, it shouldn’t be read by assistive technology. Use:
```
<span aria-hidden="true">
  <svg></svg>
</span>
```
Or:
```
<svg role="presentation"></svg>
```
This keeps screen reader output clean and focused on relevant content.

3. Pay Attention to Size, Contrast, and Focus

Accessible icons should be big enough to click easily and bold enough to see. Stick to WCAG’s minimum target size of 44×44 px. Use color contrast of at least 3:1 for non-text icons. And don’t forget to add a visible focus style for keyboard users—like a border or shadow:
```
button:focus {
  outline: 2px solid #000;
  outline-offset: 2px;
}
```
4. Stay Consistent

Use the same icon for the same action across your site. If a magnifying glass opens search in one place, don’t use it for zoom somewhere else. Consistency helps users feel confident in what each icon means—and that’s what accessible icons are all about.

5. Avoid Icon Fonts and Emojis

While they may seem handy, icon fonts can confuse screen readers. Emojis can also be read out in unexpected ways. It’s safer and more predictable to use SVG icons with proper labels.

6. Test in the Real World

Use tools like Lighthouse, or WAVE to catch basic issues. Then test manually: try navigating with a keyboard, check screen reader output, and validate that your icons have the right labels and focus states. Real-world testing is essential to making sure your accessible icons actually work.

A Closer Look: Two Icon Examples

The Right Way to Do a Menu Icon

Let’s say you’re building a mobile menu. Instead of just throwing in a hamburger icon, here’s how to make it accessible:
```
<button aria-label= "Open menu">
  <svg aria-hidden="true" width="24" height="24">
    
  </svg>
</button>
```
With proper labeling, contrast, sizing, and keyboard focus styles, this is a perfect example of accessible icons done right.

Clarifying a Heart Icon

Got a heart icon to save a product? Don’t leave users guessing. Add supporting text:
```
<button aria-label= "Save to favorites">
  <svg aria-hidden="true" width="24" height="24">
    
  </svg>
</button>
```
This helps screen readers speak the correct action and helps all users understand what it does.

Looking Ahead: The Future of Icon Accessibility

Think Global

Icons don’t always mean the same thing across cultures. Something that makes sense in the U.S. may not be clear in Japan or Brazil. When designing accessible icons, test with a global audience if your site serves one.

Customize and Personalize

If you’re creating custom icons for your brand, take extra care with labeling and testing. Better yet, offer users the ability to switch between icons, text, or both—especially for key actions. It’s all about giving people choices that fit their needs.

Final Thoughts: Make Icons That Include Everyone

Icons are powerful little tools. They help us move faster, understand more, and make the web a little smoother. But for them to work for everyone, they need to be designed with care.

That means using accessible icons that have clear labels, hiding decorative ones, following size and contrast rules, being consistent, and testing thoroughly. These steps don’t take away from good design—they enhance it.

At 216digital, we work with design and development teams to review their UI patterns and create accessible experiences—icons included. If you’re ready to take the next step in making your digital spaces more inclusive, let’s talk. Schedule your ADA accessibility briefing today and let us help you turn thoughtful design into inclusive action.
Greg McNeil

June 26, 2025

How-to Guides

Accessibility, Accessible Design, ADA Compliance, Graphic Designer, How-to, Website Accessibility
How to Identify Decorative Images for Accessibility
Images can bring a web page to life—but not all of them need to speak. When it comes to web accessibility, knowing which images are decorative and which are informative is key to creating a cleaner, smoother experience for people using screen readers and other assistive technologies. That’s where alternative text (alt text) comes in.

You probably already use alt text to describe important images. But what about the purely visual ones—those flourishes and background elements? If they don’t add value beyond appearance, they might be decorative images. This article helps you identify which images fall into that category and how to properly mark them, so screen reader users aren’t bogged down by unnecessary noise.

By focusing on even small improvements—like skipping redundant descriptions—you can build better, more respectful websites.

What Makes an Image “Decorative”?

Let’s start with the basics. According to WCAG 2.1 Success Criterion 1.1.1: Non-text Content, all meaningful non-text content must have a text alternative. But decorative images are an exception—they don’t need a description because they don’t carry meaning.

So, what exactly counts as decorative?

Common Decorative Image Types
- Borders, swirls, and flourishes that are strictly for looks
- Icons next to already-labeled buttons (like a phone icon next to the word “Call”)
- Stock photos that add mood or style but aren’t referenced in content
- Repetitive logos or design elements used as dividers or backgrounds
If removing the image doesn’t change the message or function of the page, you’re likely dealing with a decorative image.

Making the Right Call: Informative or Decorative?

It’s not always black and white. Here are a few quick questions to help:
- Does the image convey info that isn’t available in the text?
- Would a user miss out on something if the image was gone?
- Is the image part of an instructional step, chart, or link?
If you answer yes to any of these, the image is probably informative—and it needs descriptive alt text. If not, you may be safe to treat it as decorative.

For a more detailed approach, try W3C’s Alt Decision Tree. It’s a great tool, but don’t worry—no one expects you to follow it like a script. Trust your content instincts too.

Common Mistake Alert: Don’t mark company logos, charts, or instructional images as decorative. If they carry meaning or serve a function, they need proper alt text.

How to Properly Mark Decorative Images in Code

Once you’ve determined that an image is decorative, here’s how to ensure assistive technologies skip over it.

Use an Empty Alt Attribute

This is the most common and widely supported method:
```
<img src="divider.png" alt="">
```
Why does this work? A screen reader will completely ignore the image. This prevents confusion and keeps users focused on meaningful content.

But be careful: don’t skip the alt attribute altogether. Leaving it out may cause screen readers to read the file name—something like “divider-dot-p-n-g”—which is exactly the kind of noise we’re trying to eliminate.

Use role="presentation" or aria-hidden="true"

For SVGs, icons, or complex visual elements that can’t use alt="", try one of these:
```
<svg role="presentation">...</svg>
<img src="swirl.svg" aria-hidden="true">
```
What’s the Difference?
- role= "presentation" tells assistive tech: this element is just for visuals.
- aria-hidden= "true" hides the element from all assistive tech completely.
Choose one—don’t combine them with an empty alt attribute. Using both can confuse the accessibility tree and cause unpredictable results.

Best Practices & Pitfalls to Avoid

To keep your decorative images accessible:
- Use only one method to mark an image as decorative
- Test your implementation using screen reader emulators, WAVE, or Lighthouse
- Avoid using the word “decorative” in the alt text—use an empty alt attribute instead.
- Always include the alt attribute, even if it’s empty.
- Be careful not to hide meaningful images by using aria-hidden="true".
It’s also a good idea to review your CMS settings. Many platforms automatically insert images or fill alt text fields with file names. Stay alert!

Why It Matters: The Impact of Doing It Right

When you handle decorative images properly, you create a better user experience for everyone:
- Less noise for screen reader users, making it easier to navigate pages
- A clearer focus on important content and messages
- Reduced cognitive load, especially for users with visual or cognitive disabilities
- Cleaner code that’s easier to maintain and optimize
Bonus: It can even help with SEO by making your site more semantic and purposeful.

Real users have reported better experiences when extra, repetitive images are removed from their screen reader journey. It’s a small step with a big payoff.

Beyond Alt Text: Decorative Images Are Just One Part

Identifying and labeling decorative images is one part of a much larger accessibility picture. But it’s a foundational step.

Teams should regularly audit content—especially in environments where new images are often added, like blogs or e-commerce templates. Ask yourself: are new images truly meaningful, or just visual noise?

Also, remember: accessibility isn’t one person’s job. It’s a shared responsibility. Designers, devs, marketers, and content creators all play a role in making digital experiences more inclusive.

And if you’re using modern frameworks like React or Vue, be sure your components handle decorative images correctly and out of the box. A simple alt=”” on a reusable image tag can save a lot of friction.

Keep Image Accessibility Intentional

To recap: If an image is purely decorative, mark it so that screen readers skip over it. Use an empty alt="", or where needed, role= "presentation" or aria-hidden= "true". Don’t mix methods, and always test your work.

Improving how you handle decorative images might seem like a small detail, but it’s a powerful way to respect your users and refine your site’s accessibility. Thoughtful design isn’t just about how a site looks—it’s about how it feels to navigate.

Need a second pair of eyes on your accessibility implementation?

Schedule an ADA accessibility briefing with 216digital. Our experts can help you identify gaps, offer hands-on guidance, and take the guesswork out of inclusive design—so your digital experiences work better for everyone.
Greg McNeil

June 23, 2025

How-to Guides

How-to, Image Alt Text, WCAG, WCAG Compliance, web developers, web development
Descriptive Page Titles for Better Accessibility
If you’ve ever had 15 tabs open at once (and let’s be honest—who hasn’t?), you know how frustrating it is to click around trying to remember which one is which. When the titles are clear, you can find what you’re looking for in a second. When they’re not, it’s a guessing game.

For users who rely on screen readers or who live with cognitive or memory challenges, vague titles aren’t just annoying. They’re a real barrier. That’s where descriptive page titles come in. They make a huge difference in helping all users navigate the web more easily, and they support your site’s overall usability and accessibility—without requiring a major overhaul.

Best of all, it’s one of the simplest changes you can make that still packs a serious punch. A good page title improves orientation, reduces confusion, boosts your SEO rankings, and even helps reduce legal risk under the Americans with Disabilities Act (ADA). All with a few well-chosen words.

What WCAG 2.4.2 Actually Requires

Under WCAG 2.4.2—a Level A requirement in the Web Content Accessibility Guidelines (WCAG)—every web page must have a title that clearly describes its topic or purpose. It’s one of the most fundamental accessibility requirements, but it’s also one of the most overlooked.

Simply having a <title> tag isn’t enough. What’s inside that tag matters. A vague or generic title—like “Home” or “Untitled”—does little to help users understand what the page is actually about. It’s a bit like labeling all your folders “Stuff”—no one can navigate that efficiently, especially not users relying on assistive technologies.

This is especially important for screen reader users. Page titles are often read aloud as soon as a page loads or when switching between browser tabs. That brief moment of context helps them know exactly where they are. Similarly, sighted users benefit from meaningful titles when scanning through multiple open tabs or saving bookmarks for later reference.

Who Benefits from Descriptive Page Titles?

The short answer? Everyone. But here’s how it really plays out for different types of users:
- Screen reader users hear the page title as their first introduction. A vague or incorrect title can throw them off or force them to dig deeper than necessary.
- People with cognitive or memory challenges rely on titles to quickly understand whether a page is relevant. A well-written title can prevent information overload and reduce frustration.
- Mobility-impaired users benefit because they can avoid unnecessary clicks or key presses if the title tells them they’re on the wrong page.
- Everyone else—yes, even those without disabilities—appreciates descriptive page titles for the sheer convenience. Clear titles make it easier to navigate tabs, scan bookmarks, and share links confidently.
When a title says exactly what a page delivers, no one has to guess. That’s good usability—and that’s what accessibility is really about.

Common Title Mistakes (And How to Fix Them)

Even with the best intentions, many websites still fall into title traps. Let’s look at a few common problems:
- Too Vague: Titles like “Home” or “Blog” don’t help much when you’re trying to tell one tab from another.
- Reused Titles: When every blog post or account page is titled the same—like “Monthly Statement”—users lose their place quickly.
- Doesn’t Match the Page: If your title says “Pricing,” but the page is about features or FAQs, that mismatch causes confusion.
- Overloaded for SEO: You’ve seen these: “Best Home Trim Vinyl Windows Outdoor Accessories 2025 Guide.” They’re trying to do too much and end up helping no one.
Better Examples

Consider replacing generic titles with more descriptive ones. For example, swap “Blog Post” with “How to Write Descriptive Page Titles.” You might also change “Services” to “Real World Accessibility | 216digital,” or “Contact” to “Contact Us – 216digital Web Team.”

These small edits bring clarity, build trust, and boost both accessibility and SEO

Accessibility and SEO: They Work Together

There’s a common myth that writing for accessibility hurts SEO—but that couldn’t be further from the truth. In fact, descriptive page titles are a perfect example of how accessibility and SEO can work in harmony.

Search engines love pages with relevant, concise, and unique titles. So do people. That means when you follow accessibility best practices, you’re also improving your site’s visibility and user engagement.

Tips for Great Titles
- Keep them between 30–60 characters so they don’t get cut off in search results or browser tabs.
- Use primary keywords naturally, not awkwardly.
- Try using a pattern like: [Page Topic] | [Brand Name].
So, “About” becomes “About Our Team | 216digital” and “Pricing” becomes “Website Accessibility Pricing | 216digital.”

It’s easy to see how small tweaks can have a big payoff.

How to Improve Your Titles—Step by Step

Here’s a quick plan to help you get your titles in shape:

Audit Your Site

Use automated tools to spot missing, duplicate, or unusually long titles. But don’t stop there—manual review is key to catching vague or misleading language that tools might miss.

Apply a Simple Template

Keep it consistent across your site: “[Page Topic] | [Brand]” works for most needs and helps build recognition.

Loop in Your Team

Content creators, developers, designers, and SEO specialists should all care about good descriptive page titles. Make it a shared goal—not an afterthought.

Add it to Your Checklist

Whether you’re launching a new blog post, updating a product page, or doing a site redesign, reviewing the title tag should be part of the process every time.

The Risks of Getting It Wrong

Ignoring this part of accessibility can lead to bigger problems. WCAG 2.4.2 is part of ADA compliance, and missing or misleading titles are often among the first things flagged in accessibility audits. If you’re not in compliance, you could be vulnerable to lawsuits—and nobody wants that.

But beyond legal risk, failing to use descriptive page titles sends the wrong message. It suggests your site wasn’t built with every user in mind. And that hurts brand trust more than you might think.

Final Thoughts: Titles That Work for Everyone

It’s easy to overlook something as small as a page title. But when you take a step back, you’ll see that descriptive page titles affect every part of your site—from how users find you, to how they feel while browsing, to whether they come back at all.

This one fix can make your site more usable, more discoverable, and more inclusive—without blowing up your workflow or budget. That’s what we call a smart move.

Ready to Take Action?

Want help reviewing your site for accessibility wins like this one? Schedule an ADA briefing with 216digital. We’ll show you how small changes like descriptive page titles can lead to big improvements in compliance, usability, and user trust—no pressure, no hard sell.

Let’s build a web that works for everyone—starting with the title.
Greg McNeil

June 18, 2025

How-to Guides

Accessibility, How-to, Page Titles, WCAG, WCAG Compliance, Web Accessibility, web developers, web development, Website Accessibility

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?

Who’s Affected (And Why You Should Care)

Where Keyboard Traps Hide

Modals, Popovers, and Dialogs

Forms and Custom Inputs

Media Players

JavaScript-Enhanced Links

Testing for Keyboard Traps

Best Practices for Trap-Safe Code

A Safe Dropdown in Action

Build Trap Prevention into Your Workflow

Focus on What Matters

Why Accessibility in Infographics Matters

Core Principles for Accessible Infographic Design

1. Start With Simplicity

2. Organize With a Logical Structure

3. Prioritize Readable Text

Make the Visuals Understandable to Everyone

4. Provide Text Equivalents

5. Use Color With Care

Don’t Forget the Tech‑Specific Details

6. Accessible Animation (If You Use It)

7. Link Design

8. Optimize for Mobile

Test Like Accessibility Depends on It (Because It Does)

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

The Fundamentals of Accessible UX

Accessibility vs. Usability

Visual Accessibility: Making Your Content Clear

Color and Contrast: Give Every Element a Voice

Text and Typography: Keep It Clean and Comfortable

Images and Media: Describe What Matters

Links and Structure: Build a Clear Path

Auditory Accessibility: Sound That Speaks to Everyone

Motor Accessibility: Let Everyone Navigate Their Way

Cognitive Accessibility: Make It Clear, Make It Work

Accessible Design Checklist

Accessible Design Never Clocks Out

Speak Clearly: Write for Real People

Make Your Visuals Speak—To Everyone

Caption Everything: Videos and Audio

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

Sprite Systems (`<use>`) and Symbols

Use `role="presentation"` or `aria-hidden="true"`