web development Archives /Tag

How Digital Accessibility Training Reduces Legal Risk
You’ve already put in the work. Your site has been remediated, the big accessibility issues are behind you, and things are finally in a good place. That’s huge. But here’s the thing—accessibility doesn’t stay fixed on its own.

Websites evolve fast. New content gets published. Layouts shift. Design trends change. And unless your internal team knows how to keep accessibility in place, even small updates can knock you out of compliance before you realize it.

This is where digital accessibility training becomes your secret weapon. It’s not about starting over—it’s about staying in control, protecting your investment, and building confidence across your team.

Why Accessibility Isn’t “One and Done”

If you’ve ever updated a button style or added an image without checking the alt text, you already get it: accessibility issues can sneak in easily.

Every time your team touches the website—whether it’s a blog post, a product update, or a code tweak—they’re either maintaining compliance… or breaking it.

Remediation isn’t the finish line. It’s the starting point for sustainable accessibility. And without digital accessibility training, your team is basically driving without a map. One wrong turn, and you’re back in legal territory.

The Legal Stakes: Second-Time Lawsuits Are Surging

Here’s a stat that should stick: 41% of accessibility lawsuits last year were filed against companies that had already been sued before. That’s not a coincidence. It’s a sign.

Fixing things once doesn’t mean you’re covered forever. If issues come back—especially the same ones—courts notice. And they’re less patient the second time around.

Digital accessibility training helps your team catch issues early, long before they show up in a legal complaint. It’s the difference between being reactive and being resilient.

Training Makes You Proactive, Not Dependent

When your team is trained, they can:
- Spot accessibility problems in real-time
- Design and code with accessibility in mind from the start
- Review content before it goes live—not after complaints roll in
Instead of waiting for a vendor audit (and the invoice that comes with it), you can handle it in-house. That means fewer delays, fewer emergencies, and fewer costs.

Digital accessibility training empowers your team to do accessibility right—the first time.

It’s Not Just the ADA Anymore

If your organization works with government agencies, serves international users, or plans to expand globally, accessibility compliance means more than just the ADA.

You’ve got:
- Section 508 in the U.S.
- EN 301 549 in the EU
- AODA in Ontario, Canada
- And, of course, WCAG, which ties it all together
Training helps your team navigate all of it. No guessing. No scrambling. Just smart, informed decisions that keep you compliant across borders.

Why Training Costs Less (and Does More) Than You Think

Hiring outside help every time something breaks? That adds up—fast.
- Emergency audits
- Last-minute fixes
- Legal consultations
- Brand damage
Now compare that to the cost of training your internal team once—and watching them catch and prevent those issues every day.

Digital accessibility training is a one-time investment that keeps paying off. It saves time, reduces legal risk, and builds real, lasting confidence across departments.

What 216digital’s Training Really Looks Like

At 216digital, we don’t do cookie-cutter courses. Your team isn’t generic—and your training shouldn’t be either.

Here’s what our digital accessibility training includes:
- Custom learning paths based on your CMS, platform, and team roles
- Modules for designers, developers, content creators, and PMs
- Real examples from your own website
- Practical tips that match the tools you already use
- Built-in support for the remediation work you’ve already completed
This isn’t about teaching theory. It’s about building confidence and making sure your site stays accessible.

Who Needs to Be Trained?

Short answer: anyone who touches your website. Because accessibility isn’t just a dev thing. It’s not just a design thing. It’s a whole team thing.
- Developers learn to code accessibly from the ground up
- Content creators learn how to format text, links, and images the right way
- Designers learn how to make inclusive choices from the start
- QA testers learn what to look for before pushing updates live
When the whole team is on the same page, accessibility becomes second nature—not an afterthought.

A Human Approach That Actually Sticks

At 216digital, we live this stuff. We’re developers, writers, testers, and designers just like you. We’ve seen how frustrating accessibility can be when it feels like a mystery—and we’re here to make it feel manageable.

Our digital accessibility training is:
- Practical – You’ll use what you learn right away
- Approachable – No jargon, no lectures, just real conversations
- Supportive – We’re here to help, not to judge
Accessibility is about people. So is training.

The Bottom Line: Keep What You’ve Built

You’ve already made a big investment in accessibility. Don’t let it fade over time.

Digital accessibility training is how you protect that work, reduce legal risk, and give your team the tools to move forward with confidence.

Let’s make sure your website stays inclusive—for everyone who needs it.

Ready to empower your team? Learn more and schedule a custom session at 216digital.com/216digit-training
Greg McNeil

April 30, 2025

Web Accessibility Training

Accessibility, Accessibility Training, Marketing, Web Accessibility, Web Accessibility Training, web development, Website Accessibility
Building Trust Through Data Privacy and Accessibility
Picture this: you’re on a checkout page, ready to buy, when a wall of legal text blocks the button and your screen reader can’t even find the “accept” link. Do you trust that site? Most shoppers don’t—and they bail. Privacy and accessibility shouldn’t be an either-or proposition; handled together, they build instant confidence.

Too often, users are forced to choose between protecting their personal information and navigating a website with ease. A confusing privacy policy here, an inaccessible cookie banner there—and just like that, trust starts to slip. At their core, data privacy and accessibility both ask the same questions: Are we being clear? Are we giving people control? Are we including everyone? When these two efforts work together, they create a better experience for every user.

This article explores how to align your site’s approach to data privacy and accessibility, why it matters, and what steps your team can take to build real trust from the very first click.

Why Data Privacy and Accessibility Align

Data privacy is about protecting what you learn from your visitors. Accessibility is about making sure they can actually use your website. On the surface, these may seem like different goals, but they share three core principles:
- Transparency – Tell users what you do.
- Control – Let them decide how much to share.
- Inclusion – Make every tool usable.
When people understand your policies and can reach every corner of your site—whether by mouse, keyboard, or screen reader—they’re more likely to stick around, make purchases, and return again.

A Quick Primer on U.S. Privacy Rules

Let’s zoom in for a moment on data privacy laws in the U.S. Several states now give residents clear rights over their data. The California Consumer Privacy Act (CCPA) and its update, the CPRA, let users see, delete, or limit the sale of their personal details. Colorado, Connecticut, Utah, Virginia, and Oregon have passed similar laws.

Even if your company isn’t based in one of these states, chances are good that someone from those areas is visiting your site. Following the most comprehensive rules isn’t just about compliance—it’s the safest and smartest path forward for your brand.

What Accessibility Means Online

Accessibility means ensuring people with visual, hearing, motor, or cognitive disabilities can use your site. The Web Content Accessibility Guidelines (WCAG) spell out how to do this, with best practices like:
- Keyboard navigation
- Clear headings and layout
- Adequate color contrast
- Captions or transcripts for videos and audio
It’s not just about doing the right thing. Courts have increasingly linked the Americans with Disabilities Act (ADA) to public-facing websites. That makes accessibility both a quality goal and a legal imperative.

Where the Two Worlds Meet

Want to see where data privacy and accessibility collide? Just look at your cookie banner.

This is often the first thing visitors see—and it’s where trust can break in two. If the banner traps keyboard focus, lacks contrast, or can’t be closed without a mouse, users who rely on assistive tech may bounce before they even get started. In that moment, data privacy controls fail, and usability collapses.

It’s a missed opportunity. Done well, that same banner could build credibility and demonstrate respect—for choice and access alike.

Four Places Trust Can Break

Let’s look at four areas of your site where trust is most likely to falter—and how to fix it before it does.

1. Consent & Cookie Pop-Ups: The Front Door of Trust
- Say it out loud. Code the banner so screen readers announce the headline first—not the fine print.
- Keep the keyboard in the room. Maintain a clear focus ring so keyboard users never lose track.
- Use plain language. Simple buttons like “Accept,” “Decline,” and “Customize” make choices obvious.
2. Forms and Checkout
- Ask for only what you need. Don’t overreach with your data collection.
- Pair every field with a label. Avoid using placeholder text alone.
- Flag errors clearly. Use both text and color, and link error messages back to the form fields.
3. Analytics and Tracking
- Honor Do Not Track signals. Respect user intent where it’s expressed.
- Add opt-out links. Put them in your footer and make them keyboard accessible.
- Anonymize IPs. Avoid tying activity to identifiable users when possible.
4. Content Files
- Tag your PDFs. Make them searchable and readable.
- Scrub personal info. Clean downloadable files of names or sensitive data.
- Write great alt text. Describe visuals without exposing private details.
These aren’t extras—they’re basics. Nail them, and you’ll show visitors you care about both their data privacy and their ability to engage.

Building a Cross-Team Trust Framework

Trust isn’t built in one department—it’s a team effort. But in many organizations, legal, development, and marketing work in silos. That’s a recipe for gaps.

Instead, bring everyone to the table with shared goals:
- Legal writes policies in clear, eighth-grade reading level language. Add a short “Plain English Summary” at the top.
- Developers turn policy into practice. They build with WCAG 2.2 AA in mind, test with screen readers, and verify keyboard accessibility.
- Marketing respects consent signals. They use analytics tools that focus on aggregated data and avoid building detailed user profiles.
Hold short monthly standups. Each group should report progress on bounce rate, opt-out rate, and accessibility errors. When everyone has a number to own, priorities align.

Action Plan in Seven Steps

A combined data privacy and accessibility strategy doesn’t have to be complicated. Here’s a quick-start checklist:
1. Map every data touchpoint. Include forms, chats, analytics tools, and third-party scripts.
2. Run a joint audit. One checklist, two goals. Avoid duplicate work.
3. Fix high-risk issues first. Broken keyboard access on a checkout form can cost you sales—and get you sued.
4. Choose a consent platform that meets WCAG. Look for keyboard support and scalable font sizes.
5. Rewrite dense policy pages. Use short sentences, descriptive headers, and bullet points.
6. Train your team. Cover accessibility and data privacy in new hire orientation and quarterly refreshers.
7. Publish a changelog. Tell users when you update how their data is handled or how the site works. It shows you’re transparent.
Measuring Success

Trust is hard to measure—but not impossible. Here are a few indicators that your efforts are paying off:
- Fewer support tickets about navigation or login issues
- Lower cart abandonment rates
- Higher sign-ups after revising consent forms
- Better survey results when asking if users feel safe and included
Small gains in these areas show you’re on the right track. Over time, they compound into stronger customer relationships.

Final Thoughts

Trust isn’t just a design trend—it’s a survival strategy in modern e-commerce. When data privacy and accessibility go hand in hand, you create a website that feels safe, respectful, and inclusive.

And that kind of experience builds loyalty.

If you’d like a second set of eyes on both privacy and accessibility, let’s talk. At 216digital, we specialize in aligning accessibility and data privacy from the ground up. Together, we can help you build a site that earns trust from the first click—and keeps it long after the page loads.
Greg McNeil

April 25, 2025

Legal Compliance, Web Design & Development

California Consumer Privacy Act, data privacy, WCAG, web development, Website Accessibility
Accessible Form Validation: A Developer’s Guide
Forms are everywhere—login screens, signups, feedback surveys, checkout pages. They’re a cornerstone of user interaction on the web. But here’s the thing: if users can’t fill them out easily and accurately, your form isn’t just failing them—it’s failing your business.

That’s where accessible forms come in. Accessible forms aren’t just about ticking boxes for compliance—they’re about creating better experiences for everyone. Whether someone is using a screen reader, navigating with a keyboard, or dealing with cognitive or motor disabilities, your form should guide, inform, and support them from first click to final submit.

This guide will walk you through the essentials of accessible form validation, based on WCAG guidelines 3.3.1 through 3.3.4. No legalese—just practical advice you can implement today.

Meet the Guidelines: WCAG 3.3.1 to 3.3.4

Let’s simplify the four WCAG success criteria most relevant to form validation:
- 3.3.1 Error Identification: If something goes wrong, users need to know what happened and where it happened.
- 3.3.2 Labels or Instructions: Don’t make users guess. Tell them what’s required.
- 3.3.3 Error Suggestion: If they make a mistake, suggest how to fix it. Don’t just point and shake your digital finger.
- 3.3.4 Error Prevention: For serious forms (like taxes, legal documents, or financial data), build in checks to stop mistakes before they happen.
Together, these guidelines form the foundation of truly accessible forms.

Labeling: The First Step Toward Clarity

Every good form starts with clear, semantic labeling. You’re not just adding text—you’re defining meaning and context for both users and assistive technologies.
- Use the <label> element, and link it to the input with for="input-id" and id="input-id".
- Place labels above the form field, not beside or inside. It’s easier to scan and better supported by screen readers.
- Be concise but descriptive. Instead of “Name,” try “Full Name (First and Last).”
Skipping proper labels is one of the fastest ways to make your form inaccessible—and one of the easiest problems to fix.

Inline Error Messaging: Real-Time Feedback That Actually Helps

Don’t let users fill out a whole form only to learn they messed up three fields. Inline validation catches issues in real time, helping users correct them before they submit.
- Position error messages near the field—ideally right below or beside it.
- Keep the language helpful and plain: “Password must be at least 8 characters.”
- Use aria-live="polite" to announce error messages as they appear for screen readers.
This creates accessible forms that support users proactively instead of punishing them after the fact.

Don’t Skip aria-describedby

Want to add help text, error messages, or extra instructions that screen readers can pick up? Use aria-describedby.

This attribute lets you associate one or more descriptions with a form control. It’s a game-changer for accessible forms, especially when validation feedback or detailed guidance is involved.

Example:
```
<input id="email" aria-describedby="emailHelp emailError">
<small id="emailHelp">We'll never share your email.</small>
<span id="emailError">Email is required.</span>
```
You can dynamically update which IDs are referenced based on validation state, ensuring that assistive tech users always get the right context.

About Placeholders: Don’t Rely on Them Alone

We’ve all seen it: fields with placeholder text like “Enter your email,” and no label in sight. Here’s the problem: placeholders disappear as soon as users start typing—and that’s bad news for accessibility.

Use placeholders for examples, not for instruction.
- ✅ “example@example.com” is fine.
- ❌ “Enter your email address” as your only guidance? Not okay.
Also, watch your contrast ratios. Light gray placeholder text on a white background might look trendy, but it can fail WCAG color contrast guidelines—especially for users with low vision.

Smart Form Validation

Validation is about more than catching errors—it’s about building trust. If your form is flaky, unclear, or inconsistent, users will bounce.
- Use client-side validation (like HTML5 validation or JavaScript) for instant feedback.
- Always back it up with server-side validation to catch anything missed and guard against malicious input.
- Block submission until all required fields are valid—and clearly explain why a field isn’t.
Whether it’s a missed checkbox or a mistyped phone number, your form should guide users toward fixing the issue—not leave them guessing.

Crafting Helpful, Accessible Error Messages

Bad error messages are like bad customer service: unhelpful, vague, and frustrating. Let’s fix that.
- Be specific: “Username is required” > “Error.”
- Never rely on color alone (like red borders) to indicate problems. Use symbols (like ❗), text, or both.
- Keep error placement consistent—typically below the input or in the same visual region.
- Use simple language. If someone has to decode your error message, it’s not helping.
This clarity benefits everyone—from screen reader users to someone filling out your form on a noisy subway.

Test It Like You Mean It

Automated tools are great, but they only catch part of the picture.

Start with:
- Lighthouse for quick audits.
- WAVE for spotting contrast or structural issues.
Then go deeper:
- Run through the form with keyboard only—can you reach and complete every field?
- Try it with a screen reader (VoiceOver, NVDA, JAWS). Does it announce labels, instructions, and errors?
- Ideally, test with real users with disabilities. There’s no substitute for lived experience.
Accessible forms are never a “one-and-done” task. They’re a process—build, test, refine, repeat.

Keep Moving Toward More Accessible Forms

Every form you build is an opportunity to include—or exclude—someone. Whether it’s a simple newsletter signup or a detailed application, accessible forms ensure everyone gets a fair shot at completing the task.

This isn’t just about compliance. It’s about craftsmanship. It’s about building smarter, kinder digital experiences—ones that don’t leave users behind.

Need help building forms that meet WCAG standards and feel good to use? Connect with 216digital. We’ll help you create, audit, and refine accessible forms that work for every user—and every device.
Greg McNeil

April 18, 2025

How-to Guides

Accessibility, ADA Compliance, forms, How-to, WCAG, Web Accessibility, web development, Website Accessibility
How GDPR and CCPA Are Shaping Data Privacy
Data privacy isn’t a new concept. Businesses have been managing sensitive customer information for decades—through paper files, databases, CRMs, and now digital platforms. What has changed is the growing expectation that people should have control over their own data. Laws like the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) didn’t invent data privacy—but they’ve redefined the standards.

These regulations are reshaping how organizations around the world approach data—how they collect it, store it, share it, and most importantly, how they communicate about it. If you’re leading a business, managing digital operations, or overseeing customer experience, understanding how these laws work isn’t just a compliance task—it’s a strategic advantage.

What the CCPA Introduced to U.S. Businesses

When the CCPA took effect in 2020, it marked a turning point for U.S.-based organizations. For the first time, there was a law that gave American consumers—not just businesses—clear, enforceable rights over their personal data. It caught many companies off guard.

California residents gained the legal right to:
- Know what personal information is being collected about them.
- Request the deletion of that information.
- Opt out of the sale of their data.
For businesses, this meant a new level of transparency. You needed to disclose how data was being used, offer clear opt-out tools, and ensure your privacy policies were not only accessible—but written in plain, understandable language.

This wasn’t just about legal boxes to check. It was about shifting power. CCPA put the customer in the driver’s seat.

A Ripple Effect Beyond California

Even though the CCPA is a state law, its impact has reached far beyond California’s borders. Why? Because any business that serves California residents—regardless of location—has to comply. And for companies with customers across the U.S., it simply made sense to raise privacy practices across the board.

That’s why CCPA didn’t stay a California issue. It sparked national conversations, boardroom discussions, and policy rewrites. It also paved the way for other states to create their own laws. Virginia, Colorado, Connecticut, and Utah have already passed privacy regulations of their own. Each carries unique nuances, but most borrow heavily from the same foundational ideas introduced by the CCPA and GDPR.

The GDPR: Setting the Global Standard

Before CCPA came onto the scene, there was GDPR. Introduced by the European Union in 2018, the General Data Protection Regulation quickly became the global benchmark for data privacy.

Its scope was ambitious—and intentional. GDPR applies to any organization, anywhere in the world, that processes data from EU citizens. Whether you’re based in Paris, New York, or Singapore, if your business interacts with European customers, you’re expected to comply.

Core GDPR Requirements:
- Consent: Businesses must get clear, informed consent before collecting personal data.
- Right to Be Forgotten: Individuals can ask for their data to be deleted permanently.
- Breach Notification: Organizations must report data breaches within 72 hours.
- Data Portability: Consumers have the right to access and transfer their own data.
The GDPR’s influence is still growing. Many new laws—both in the U.S. and abroad—are built using GDPR as a model. And in the absence of a single U.S. federal privacy law, many organizations default to GDPR compliance as a way to meet the highest global standard.

GDPR vs. CCPA: Two Paths, One Direction

While GDPR and CCPA share the same underlying goal—giving people more control over their personal data—they approach it in different ways.

Who’s Affected?
- GDPR: Global reach. Applies to any company handling EU data.
- CCPA: U.S.-based, but applies to companies interacting with California residents.
Consumer Rights
- GDPR: Offers broad rights—access, deletion, correction, portability.
- CCPA: Emphasizes transparency, deletion, and the right to opt out of data sales.
Consent Models
- GDPR: Requires proactive, upfront permission.
- CCPA: Allows post-collection opt-outs, which can be more flexible for businesses but less direct for consumers.
The differences matter—but the direction is the same. Regulators are moving toward greater accountability, and consumers are demanding more clarity and control.

A Growing Patchwork of U.S. Laws

The U.S. now faces a growing number of state-level privacy laws, each with its own requirements and timelines. Virginia’s VCDPA, Colorado’s CPA, and Connecticut’s CTDPA are just a few of the new players. While many reflect GDPR or CCPA in principle, the details vary—and that’s where things get tricky.

For multi-state businesses, managing these differences isn’t just time-consuming—it can be a real risk. You’re not just dealing with technical updates to your website. You’re coordinating privacy notices, opt-out mechanisms, data retention policies, and more—often with overlapping or conflicting requirements.

A unified federal privacy law, like the proposed American Privacy Rights Act (APRA), could help simplify things. However, with delays in Congress and shifting political priorities, that kind of clarity is still out of reach.

What You Can Do Now

So what’s the path forward? The answer isn’t to wait for regulation to catch up—it’s to lead with purpose.

1. Map Your Data

Know what you’re collecting, where it’s stored, who has access, and why. Without a clear inventory, compliance is guesswork.

2. Strengthen Your Privacy Policy

Make sure your privacy policy is accurate, accessible, and written in plain language. Your customers—and regulators—should understand it without needing a legal degree.

3. Build in Flexibility

Invest in systems and processes that can adapt. Privacy laws will continue to evolve. Your infrastructure should be ready to scale with them.

4. Respect User Rights

Whether it’s a GDPR data access request or a CCPA opt-out form, your business should respond quickly, clearly, and respectfully. That responsiveness builds trust.

5. Lead with Transparency

Customers don’t expect perfection. But they do expect honesty. Be upfront about what data you collect and how you use it. When in doubt, over-communicate.

Final Thoughts

Data privacy isn’t a passing trend—it’s a defining feature of the modern digital experience. And laws like GDPR and CCPA aren’t just compliance checklists. They’re a signal that the world is changing, and that businesses are expected to change with it.

The companies that embrace this shift—proactively, strategically, and transparently—will be the ones that win customer trust and loyalty over the long term.

If you’re looking for help navigating this evolving landscape, 216digital is here to support you. Schedule a privacy and accessibility briefing with our team and take the first step toward smarter, future-ready data practices.
Greg McNeil

April 14, 2025

Legal Compliance, Web Design & Development

CCPA, data privacy, GDPR, web development
How to Use aria-describedby for Web Accessibility
Have you ever looked at a form, seen the bold text or red borders, and instantly known what to do next? That’s because as visual users, we get a lot of clues from layout, color, and spacing. But for someone using a screen reader, those visual hints don’t exist. Instead, they rely on code—programmatic clues—to make sense of what’s on the screen.

That’s where aria-describedby comes in. If you’ve ever struggled to make a form, button, or modal accessible, you’re not alone. aria-describedby is a powerful tool that helps users understand what’s happening—if you use it right.

In this article, I’ll walk you through how to use aria-describedby the right way. We’ll go through practical code examples, real use cases, and common mistakes. I’ll also show you how it ties into making things like captions and subtitles more accessible, especially for users with assistive technology.

Unpacking aria-describedby

aria-describedby lets you link an element to other content that gives extra detail. It points to the ID(s) of one or more elements that contain helpful text. Think of it like this:
- aria-labelledby gives something its name.
- aria-describedby gives it extra explanation.
If a screen reader sees an input with aria-describedby= "pw-hint", it will read the input label and the hint.

Why It’s Important

Used correctly, aria-describedby helps you meet the Web Content Accessibility Guidelines (WCAG) success criteria. It improves accessibility for users who rely on screen readers. It’s especially helpful when native HTML doesn’t cover all the information a user needs. This matters for users navigating complex interfaces—like forms, modals, or media players with captions and subtitles.

When Should You Use aria-describedby?
- Form fields: Add help text or error messages.
- Buttons: Clarify what will happen, especially for destructive actions.
- Dialogs/modals: Explain what the dialog is for.
- Tooltips: Offer extra information without cluttering the interface.
- Live status updates: Let users know when things change, like upload progress or loading indicators.
aria-describedby can even support captions and subtitles in video players by giving extra context for the screen reader user, describing what’s happening beyond the visual content.

When Not to Use It
- If HTML already does the job (like using <label> or <fieldset>).
- If it adds repetitive or unnecessary text.
Code Walkthroughs: Real-World Examples

Let’s get into some code. These examples show how to use aria-describedby in ways that make a real difference.

Form Fields

Password Requirements
```
<label for="pw">Password</label>
<input type="password" id="pw" aria-describedby="pw-hint">
<p id= "pw-hint">Password must be at least 12 characters long and include a number.</p>
```
Error Messages
```
<label for="email">Email address</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="error">Please enter a valid email address.</p>
```
Multiple Descriptions
```
<input type="text" id="username" aria-describedby="username-req username-tip">
<p id="username-req">Must be at least 8 characters.</p>
<p id="username-tip">Displayed on your profile.</p>
```
Buttons

Destructive Action Explanation
```
<button aria-describedby="delete-desc">Delete Account</button>
<p id= "delete-desc">This will permanently remove your account and all data.</p>
```
Dialogs and Modals

Accessible Dialog
```
<div role="dialog" aria-modal="true" aria-labelledby="dialogTitle" aria-describedby="dialogDesc">
  <h2 id="dialogTitle">Confirm Deletion</h2>
  <p id= "dialogDesc">This action is permanent and cannot be undone.</p>
</div>
```
Tooltips and Live Regions

Accessible Tooltip
```
<input type="text" id="first" aria-describedby="tip1">
<div id="tip1" role="tooltip">Optional field.</div>
```
Status Messages
```
<div aria-describedby="upload-status">
  <input type="file" onchange="showUploadStatus()">
  <div id="upload-status" aria-live="polite">Uploading...</div>
</div>
```
These techniques can also apply to custom media players. You can use aria-describedby to point to captions and subtitles that are visible on screen but also need to be announced programmatically.

Common Mistakes to Avoid
- Too Many Descriptions: Linking to 3 or 4 IDs might overwhelm users.
- Broken References: Make sure every ID you point to actually exists.
- Redundant Content: Don’t repeat what’s already in the label.
- Timing Issues: Don’t change the text dynamically during focus unless absolutely necessary.
- Inconsistent Patterns: Keep your approach consistent across similar components.
Best Practices for Effective Implementation
- Write Clear Descriptions: Keep them short, useful, and easy to understand.
- Avoid Jargon: Explain things in plain language.
- Keep Descriptions Visible: If possible, don’t hide the text—what helps screen reader users can help sighted users, too.
- Use Native HTML First: ARIA is a supplement, not a substitute.
- Test Often:
  - Use screen readers like NVDA, JAWS, and VoiceOver.
  - Test in browsers like Chrome, Firefox, and Safari.
- Stay Consistent:
  - Create reusable components.
  - Document your design patterns.
  - Automate accessibility checks.
This also applies to any content with captions and subtitles—they should be clearly described in a way that works for both visual and non-visual users.

Beyond the Code: Organizational Tips
- Code Reviews Should Include Accessibility
- Use Linters and Audits: Tools like Google Lighthouse or WAVE to catch ARIA barriers.
- Add Accessibility to Your QA Checklist
- Train Your Team: Make sure everyone knows what ARIA does and doesn’t do.
If you’re building tools with captions and subtitles, include accessibility from the start. Don’t bolt it on later.

Accessible Descriptions, Better UX

aria-describedby is one of those quiet heroes of accessibility. It helps fill the gaps between what users see and what assistive tech can tell them.

Used well, it improves the user experience for everyone—not just people using screen readers. It’s especially helpful in forms, dialogs, and anything with captions and subtitles, where the added context can be critical.

So remember: use aria-describedby intentionally, test it thoroughly, and keep your patterns consistent. And if your team needs help making your site or app more accessible, 216digital offers expert guidance to help you meet compliance standards—while creating a better experience for all users.

Let’s keep building an internet that works for everyone. One line of code at a time.
Greg McNeil

April 11, 2025

How-to Guides

ARIA, aria-describedby, How-to, Web Accessibility, web developers, web development, Website Accessibility
eCommerce Accessibility: Cart & Checkout Best Practices
As a front-end developer, you already know how much the small stuff matters—clear labels, logical tab order, and meaningful feedback. These details don’t just polish the experience; they make the difference between a site that works for everyone and one that silently shuts people out. When it comes to eCommerce accessibility, gaps tend to show up in the usual suspects: shopping carts, forms, payment flows, and filters.

Below, we’ll explore common eCommerce accessibility gaps and show you how to fix them. You’ll see examples of HTML and ARIA attributes that make a real difference in usability—without requiring you to overhaul your entire site. Just clean, thoughtful code that helps your work reach more people, the way it’s meant to.

Why Accessibility Matters in E-Commerce

Better eCommerce accessibility results in a better user experience. When you streamline navigation, label form fields properly, and offer multiple payment methods, you’re benefiting everyone, not just shoppers with disabilities. You’re also opening your doors to more customers, including those who use screen readers, have limited mobility, or simply prefer an intuitive layout.

Beyond enhanced usability, there’s also the legal side. Lawsuits related to eCommerce accessibility are on the rise. Addressing accessibility from the start can help reduce legal risks, but the bigger win is ensuring all potential customers feel welcome in your store.

eCommerce accessibility often breaks down at a few critical points:
- Shopping carts with unclear or missing labels.
- Forms and checkouts that don’t offer proper error messages.
- Payment flows that are dependent on inaccessible CAPTCHAs or limited payment methods.
- Product filters that are keyboard-incompatible or lack clear feedback.
If you’re a developer responsible for these features, you’re in the perfect position to fix these problems. A few strategic lines of code or well-placed attributes can help transform a confusing checkout into a seamless experience for all.

Making Your Shopping Cart Work for Everyone

Add Clear Labels (Yes, Even for Buttons)

It’s a common oversight to have buttons or icons without descriptive text. Screen readers can’t interpret an icon unless you provide an aria-label or similar attribute. Give every button clear text or an invisible descriptor for assistive tech.
```
<button aria-label="Remove item from cart">
  Remove
</button>
```
This simple step ensures that anyone using a screen reader knows exactly what action they’re about to take.

Let People Update Cart Items Without Guesswork

Quantities, item removals, and other cart updates should be straightforward. If you’re using a numeric input, label it properly so a screen reader user knows what they’re adjusting.
```
<label for="quantity">Quantity:</label>
<input type="number" id="quantity" name="quantity" min="1" value="1">
```
When quantity fields are clearly labeled and keyboard-friendly, customers can adjust items easily—no mystery involved.

Show Helpful Feedback When Things Go Wrong

Errors happen: maybe a shopper enters an invalid quantity or tries to remove an item that’s no longer in stock. Instead of reloading the entire page (and frustrating users), use an aria-live region to announce errors in real-time:
```
<div role="alert" aria-live="assertive">
  Error: Please enter a valid quantity.
</div>
```
This alerts people using screen readers without forcing them to refresh or hunt for an error message.

Shipping Forms That Are Easy to Use (and Easy to Navigate)

Use Straightforward, Consistent Labels

Forms can become confusing if users aren’t sure what to type. Proper <label> tags tied to the correct inputs make a huge difference for both sighted customers and those using assistive tech.
```
<label for="address">Shipping Address:</label>
<input type="text" id="address" name="address">
```
When labels are descriptive and consistent throughout the form, everyone knows exactly what information to provide.

Make Sure Users Can Tab Through Fields Logically

Keyboard-only users often navigate by pressing the Tab key. If your form fields aren’t in a logical sequence, they’ll jump around unpredictably. Paying attention to the natural DOM order is usually enough, but if you must alter it, use tabindex carefully.

Show Errors Clearly and Offer Suggestions

Generic error messages like “Invalid input” force users to guess what they did wrong. Instead, offer specific guidance so people know exactly how to fix the issue:
```
<div role="alert">
  Error: ZIP code must be five digits.
</div>
```
This clarity benefits everyone, speeding up the checkout process and reducing frustration—two big wins for eCommerce accessibility.

Designing a Payment Flow That’s Smooth and Inclusive

Offer More Than One Way to Pay

Variety in payment methods—credit cards, PayPal, Google Pay, Apple Pay, etc.—ensures different shoppers can complete purchases in a way that suits them. Some assistive technologies work better with certain payment platforms, so having options expands your customer reach.

If You Use CAPTCHAs, Make Them Accessible

Nothing derails a checkout faster than an inaccessible CAPTCHA. If possible, rely on server-side checks. If you do need a CAPTCHA, consider offering an audio version or a more user-friendly alternative. This prevents people with disabilities from being locked out at the final step of their eCommerce accessibility journey.

Choose Accessible Payment Gateways

Third-party payment platforms can introduce new accessibility issues. Do a quick review to ensure any external gateway meets basic WCAG standards and is compatible with screen readers and other assistive tools. Even the best checkout flow can fail if the final payment step isn’t accessible.

Don’t Let Product Filters Be a Barrier

Make Filters Keyboard-Friendly

Checkboxes, sliders, and dropdowns all need to be navigable via keyboard. That means ensuring users can Tab to each control, use arrow keys for sliders, and press Enter or Space to toggle checkboxes or confirm a selection.

Let Users Know What Filters Are Applied

Always make it clear which filters are currently active, both visually and programmatically (via ARIA attributes). This helps sighted users and people using screen readers track their selections and remove or adjust filters easily.

Stick to Native HTML Controls When Possible

While custom-styled checkboxes and radio buttons can look appealing, they often introduce accessibility quirks. Native HTML elements are easier to make accessible:
```
<fieldset>
  <legend>Filter by Size</legend>
  <label><input type="checkbox" name="size" value="small"> Small</label>
  <label><input type="checkbox" name="size" value="medium"> Medium</label>
  <label><input type="checkbox" name="size" value="large"> Large</label>
</fieldset>
```
You can style them to fit your brand while ensuring they work out of the box for most assistive tech. It’s one of the easiest ways to improve eCommerce accessibility.

Testing and Validating Your Work

Start with Automated Tools (But Don’t Stop There)

Tools like Google Lighthouse and WAVE are great starting points. They scan for many common issues, but automated tests can’t cover everything, especially more nuanced user interactions.

Test Manually with Real Assistive Tech

Grab a screen reader like NVDA (Windows) or VoiceOver (Mac). Try using only your keyboard to navigate the site. This hands-on approach reveals a lot about real-world usability that automated checks might miss—especially in areas related to eCommerce accessibility.

Get Feedback from Real Users

If you can, involve people with disabilities in your testing. Their direct experience helps pinpoint issues you might never notice on your own. Real-world feedback is invaluable for refining the shopping journey.

Small Fixes, Big Impact

Building an accessible eCommerce site doesn’t require a complete overhaul. Most improvements, like adding clear labels or structuring forms properly, are quick, incremental changes in your code. These small fixes can significantly enhance the experience for shoppers who rely on assistive technology—and often make the site more pleasant for everyone else as well.

If you want more detailed guidance or an expert review, there are plenty of resources on WCAG and web.dev. You can also team up with 216digital, where we specialize in making sure online stores meet eCommerce accessibility standards from start to finish. Whether you need help with checkout flows, product filtering, or a full-site audit, our team is here to ensure every shopper can complete their purchase with ease.

Remember: inclusive design isn’t just a checkbox—it’s a mindset. By prioritizing eCommerce accessibility at each step of your development process, you’ll build online shopping experiences that truly welcome everyone. And that’s good business for everyone involved.
Greg McNeil

April 4, 2025

How-to Guides

Accessibility, ecommerce website, How-to, WCAG Compliance, Web Accessibility, web developers, web development, Website Accessibility
Accordion Accessibility: Common Issues & Fixes
Organizing content effectively on the web is about more than just layout—it’s about usability and inclusivity. When users are forced to scroll through long pages of uninterrupted text, the experience becomes inefficient and frustrating.

Enter accordion components: interactive UI elements that allow content sections to be expanded or collapsed. When implemented correctly, accordion accessibility streamlines navigation and improves content organization. However, if accessibility is overlooked, these helpful components can quickly become barriers.

This guide explores how to design accessible accordion components that enhance the user experience and meet all users’ needs—regardless of their abilities. We’ll cover best practices for structure, semantics, ARIA attributes, keyboard support, and implementation strategies to help you build inclusive, user-friendly interfaces.

Why Accordion Accessibility Matters

Accordions are essential: they reduce visual clutter and allow users to interact with content on their terms. Whether it’s an FAQ page, a product feature breakdown, or technical documentation, accordions help surface only the content that matters at the moment.

However, it’s crucial to remember that not all users interact with content similarly. Screen reader users, keyboard-only users, and others with varying access needs must be able to operate accordions just as easily as those using a mouse or touchscreen. Accessible design isn’t just a nice-to-have—it’s an essential component of responsible development.

The Building Blocks of an Accordion Accessibility-Friendly Component

1. Structure: Header and Panel

Every accordion should be composed of two core parts:

Header (Trigger)

A clickable element (typically a <button>) that users activate to show or hide content. It usually includes a descriptive label and may feature visual indicators like arrows or plus/minus icons.

Panel (Content)

The content is associated with the header. It should be hidden from view and keyboard focus when collapsed and fully accessible when expanded.

For effective accordion accessibility, each header must be clearly linked to its corresponding panel—visually for sighted users and programmatically for assistive technologies.

2. Keyboard Navigation

One of the most common accessibility pitfalls with accordion components is insufficient keyboard support. If users can’t operate your interface without a mouse, it’s not accessible.

Your accordion must support the following interactions:
- Tab / Shift + Tab: Move between focusable elements, including accordion headers.
- Enter or Space: Expand or collapse the currently focused header.
- Arrow Up / Arrow Down: Navigate between accordion headers.
- Home / End: Jump to the first or last header within the accordion group.
By supporting these interactions, you ensure that keyboard users have the same level of control as mouse users.

3. Use Semantic HTML

Semantic HTML provides the backbone of accessibility. It ensures assistive technologies can understand the structure and function of your content without additional cues.

Best Practices for Accordion Accessibility
- Use heading elements (<h3>, <h4>, etc.) to maintain the document outline.
- Place a <button> inside the heading to toggle visibility.
- Wrap panel content in a <div> that follows its associated button.
Why <button> and not <div> or <a>?

Buttons are keyboard-focusable by default, accessible to screen readers, and support interactions like Enter and Space. Enter and Space. If you rely on <div> or <a> for toggling, you’ll need extra code to achieve the same level of accordion accessibility.

4. Implementing ARIA Attributes

ARIA (Accessible Rich Internet Applications) attributes enhance accessibility when native HTML doesn’t fully express an element’s role or state. In custom accordions, these attributes help communicate dynamic behavior to assistive technologies.

ARIA Attributes for Accordion Accessibility
- aria-expanded: Indicates the panel’s expanded (true) or collapsed (false) state. Applied to the button.
- aria-controls: Points to the id of the panel controlled by the button.
- aria-labelledby: Applied to the panel, this links it back to its header button for context.
- aria-hidden:Use decorative icons or non-informative content to prevent screen readers from announcing them.
These attributes ensure that screen reader users receive clear, relevant information about the accordion’s behavior and structure.

Implementation Examples

Option 1: Native HTML with <details> and <summary>

For a semantic-first approach, HTML offers a native accordion-like behavior:
```
<details>
  <summary>Shipping Information</summary>
  <div>
    <p>We offer free shipping on orders over $50...</p>
  </div>
</details>
```
Pros
- Minimal code
- Built-in keyboard support
- Accessible by default in modern browsers
Cons
- Styling can be limited
- Inconsistent support across all assistive technologies
This is a great lightweight option for simple use cases but may fall short in more complex interfaces.

Option 2: Custom JavaScript Accordion with ARIA

If you need more control, a custom accordion allows full styling and behavior management—just be sure to handle accordion accessibility properly.

HTML Structure
```
<h3>
  <button aria-expanded="false" aria-controls="panel1" id="accordion1">
    Shipping Info
  </button>
</h3>
<div id="panel1" role="region" aria-labelledby="accordion1" hidden>
  <p>We offer free shipping on orders over $50...</p>
</div>
```
JavaScript snippet
```
const buttons = document.querySelectorAll('button[aria-expanded]'); buttons.forEach((button) => { const toggleAccordion = () => { const expanded = button.getAttribute('aria-expanded') === 'true'; button.setAttribute('aria-expanded', String(!expanded)); const panel = document.getElementById(button.getAttribute('aria-controls')); panel.hidden = expanded; }; button.addEventListener('click', toggleAccordion); button.addEventListener('keydown', (event) => { if (event.key === 'Enter') { toggleAccordion(); } }); });
```
This implementation not only handles basic interaction but also improves navigation for keyboard users. Combined with semantic structure and ARIA, it creates a robust and inclusive experience.

Best Practices to Keep in Mind
- Use Clear Labels: Avoid generic labels like “Section 1.” Use descriptive headers that make sense out of context.
- Provide Visual Cues: Arrows or plus/minus icons help users understand that a section is expandable. Consider animations that reinforce open/close behavior.
- Maintain Focus Indicators: Never remove focus outlines unless you’re replacing them with custom indicators that are just as visible.
- Be Selective with Accordions: Don’t hide critical content. It should be visible by default if the information is essential (e.g., pricing, legal disclaimers).
Testing Accessibility

Even well-intended implementations can miss the mark without testing. Include accessibility testing as part of your development workflow:
- Keyboard-Only Testing: Navigate the accordion entirely by keyboard.
- Screen Reader Testing: Use tools like NVDA, JAWS, or VoiceOver to check for correct announcements.
- Automated Tools: Run your component through tools like WAVE, or Lighthouse to identify missing attributes or ARIA misuse.
- Manual Code Review: Double-check that all attributes, labels, and roles are properly implemented.
Final Thoughts

Accessible accordions do more than organize content—they foster a better, more inclusive web. By prioritizing structure, semantics, ARIA roles, and thoughtful interaction design, you empower all users to engage with your content meaningfully.

If you’re unsure where to start or want to ensure your components meet accessibility standards, consider working with an experienced accessibility partner like 216digital. We specialize in helping teams build digital experiences that work for everyone—by default, and with accordion accessibility baked in.
Greg McNeil

March 27, 2025

How-to Guides

Accessibility, accordion, accordion accessibility, How-to, web developers, web development, Website Accessibility
When Is a Skip Link Needed?
We’ve all been on websites that greet us with massive headers, menu bars crammed full of links, or flashy ads stretching across the top. With a mouse, you can scroll or click straight to the section you care about. But if you rely on a keyboard, you’re stuck tabbing through every link and button in that menu before you reach the main story. It can feel like trudging through a maze when you just want to dive into the content.

A skip link offers a simple shortcut: it lets keyboard users jump over that repeated stuff and land exactly where they need to be. In this article, we’ll explore how skip links fit into the Web Content Accessibility Guidelines (WCAG), why they matter for anyone who doesn’t browse with a mouse, and how they can make a site more enjoyable for all visitors—even the ones who love to scroll.

What Is WCAG’s Bypass Blocks Rule?

WCAG’s Success Criterion 2.4.1, known as “Bypass Blocks,” focuses on letting users skip past content that appears on every page, such as headers, navigation menus, and sidebars. These areas can become barriers for people who rely on keyboard navigation or use screen readers, since they have to listen to or Tab through every link each time they land on a new page.

Mouse users can ignore repeated elements by moving their cursor directly to the main section of the page. But if you are using a keyboard only, you have to press the Tab key multiple times to get beyond the menu or header. This extra effort can be frustrating. By contrast, a skip link makes it possible to jump straight to the main content with a single press of the Tab key and an Enter or Space to activate it. Cutting down on keystrokes is a big boost to usability and can remove physical strain for users with motor disabilities.

Do Landmarks and Headings Count as Bypass Tools?

Some people think that WCAG’s requirements force you to include a skip link no matter what. However, WCAG does not specifically demand that you place a “Skip to Main Content” link on your pages in every scenario. If you use proper HTML5 sectioning elements like <main> or set up ARIA landmarks with role= "main", you can fulfill the technical requirement.

When you use clear heading structures (<h1>, <h2>, etc.) and assign landmarks (role= "navigation", role= "banner") to your layout, many screen readers allow users to jump from one landmark or heading to another. This means they can skip large chunks of repeated content. However, there is a key drawback: these landmark shortcuts are tied to assistive technology. Keyboard-only users without a screen reader do not benefit from these features, because landmarks are not accessible through simple keystrokes like Tab. That is where a skip link proves especially helpful, providing an obvious and direct way to move focus into the main content.

Why a Skip Link Is Still Best Practice

Even if you are technically compliant with WCAG, many experts still recommend a skip link. Here’s why:
1. Keyboard-Only Users: Landmarks may help screen reader users, but they are not available to someone who only has a keyboard. A skip link is the only direct and reliable way to jump over repetitive elements.
2. Users with Motor Disabilities: Each extra keystroke can cause strain. Reducing the need to press Tab repeatedly makes it easier for people with limited mobility to explore your site.
3. Users with Cognitive Disabilities: Repeated menus and banners can be visually overwhelming and distracting. A skip link streamlines the experience by letting users focus on the main content faster.
Other Tools That Help With Page Navigation
- Provide a Skip Link: A short text-based link such as “Skip to Main Content” at the top of the page is a universal solution.
- Use HTML Sectioning Elements: Properly labeling <header>, <main>, and <footer> can help screen reader users identify page sections.
- Implement a Logical Heading Structure: When headings form a clear outline, it is easier for people to scan or jump to key areas, especially when assistive technology is involved.
Alternative Navigation Aids

While a skip link is vital, it’s not the only accessibility tool you can use. ARIA landmarks, for example, let you define elements like role= "navigation", role= "banner", or role= "main". Screen readers can use these roles to move focus to each region. Another strategy is to include access keys, which assign keyboard shortcuts to major parts of your site. Yet, these approaches are typically helpful only to those who know how to use them and have compatible assistive technology. For most keyboard users, a skip link remains the clearest and simplest tool.

How to Add a Skip Link the Right Way

A skip link should do more than just jump down the page; it needs to work with the keyboard in a smooth way. Here’s how:

Position the Link as the First Focusable Element

The best practice is to place the skip link at the very top of your page. This ensures it is the first element that gets focus when someone tabs through the page. A common method is to link to the main content area, marked by an ID like id= "main-content".

Ensure Proper Keyboard Functionality

When users activate the skip link, focus should land right on the main content area. For this to happen, that target element must be focusable. If <main> or the first heading is not normally focusable, you can add tabindex= "-1" to make it work. This step also helps users who use screen magnifiers, because the focus moves right to the main section visually.

Example:
```
<a href="#main-content">Skip to Main Content</a>


<main id="main-content" tabindex="-1">
    
</main>
Or, if you want to move focus to the first heading:
<a href="#first-heading">Skip to Main Content</a>


<h1 id="first-heading" tabindex="-1">Welcome to Our Site</h1>

```
Ensure the Skip Link Is Visible When Focused

Many designers hide the skip link until it gains focus. While this can keep the page looking tidy, it’s important that the link is fully visible and noticeable the moment someone tabs onto it. This visibility ensures that keyboard users know there is a helpful tool available. In some designs, leaving the skip link in plain sight all the time may be the best approach.

Mistakes to Avoid With Skip Links

Even if you add a skip link, a few errors can stop it from working as intended:
- Improper Hiding Techniques: If you use display: none; or visibility: hidden;, screen readers will not detect the link at all. Instead, use off-screen positioning so it remains accessible.
- Non-Focusable Targets: Forgetting to add tabindex= "-1" to the target means the user might land near the content but not actually focus on it. This can confuse people using screen readers or screen magnifiers.
- Skipping Too Much Content: Your skip link should jump over repeated menus, but it should not force users to skip crucial information, like an important heading that explains the page’s purpose.
Check That Your Skip Link Actually Works

Testing makes sure your skip link works well:
1. Keyboard Testing: Turn off your mouse and try to navigate the site by tapping through. Watch for the link to show up, and check that it drops you into the main area.
2. Assistive Technology Testing: Use a screen reader to confirm that your skip link is announced and that it moves focus correctly.
3. Cross-Browser Compatibility: Test in different browsers (Chrome, Firefox, Safari, Edge) to confirm that the skip link behaves the same everywhere.
Make Navigation Easy for Everyone with 216digital

Including semantic elements and ARIA landmarks can make your site meet the minimum requirements of WCAG, but offering a dedicated skip link goes a step further by improving usability for keyboard-only users, people with motor disabilities, and users who may become overwhelmed by repeated menus. Rather than viewing accessibility as a set of rules to follow, think of it as a way to create a smoother, more welcoming experience for all.

If you want a site that not only checks the compliance box but also feels inclusive to every visitor, consider working with a partner who understands the importance of thoughtful navigation. At 216digital, we specialize in designing web experiences that work for everyone. A skip link may seem like a small touch, but it can make a world of difference for those who need it. Let’s make the web more inclusive together.
Greg McNeil

March 21, 2025

How-to Guides

skip link, WCAG, WCAG conformance, web developers, web development
Getting Focused: Why Focus Order Matters for Web Accessibility
Most people never think about what it would be like to navigate a website without using their mouse. This is a reality for many users with visual or motor impairments. They rely on using other input modalities, such as the keyboard or gestures, to navigate a web page. This is where focus order comes into play.

In this post, we’ll look at what focus order is, why it’s so important, how it connects to the Web Content Accessibility Guidelines (WCAG), and the most common issues you’ll want to fix. Then, we’ll share a few tips on how to test and improve it on your own site.

Life Without a Mouse

Picture going through your favorite website using only your keyboard. You press Tab to jump from one link or button to another. If the focus order is set up right, you’ll move through the page in a smooth, logical sequence, usually from top to bottom. But if it’s not, you could land somewhere unexpected or miss entirely essential parts of the page.

For anyone who can’t use a mouse, a messed-up focus order often leads to frustration. Improper focus order can lead to the cursor jumping around the page illogically or preventing them from using necessary functionality.

Avoiding Common Pitfalls
1. Skipping Interactive Elements: If a link or button is not coded using the proper semantic HTML tag or does not have the correct attributes, it will not be focusable at all, and users who can’t use a mouse will be unable to interact with the element.
2. Jumping in Strange Ways: If you rely on random tabindex values or a messy HTML structure, the focus may go from the header to a random footer link before bouncing back up. That’s tough to follow.
3. Getting Trapped: Pop-ups, modals, and iframes can trap keyboard users if the code doesn’t let them tab out. People might get stuck until they refresh the page.
4. Invisible Focus: Many designers, developers, or store owners choose to hide the focus outlines for aesthetic purposes without realizing how many people rely on them to navigate the site. Without visible focus outlines, motor-impaired users have no idea which element is currently focused on or selected.
The WCAG Connection

Focus order plays a key role in meeting the standards laid out in WCAG. Some of the main ones include:
- 2.4.3 (Focus Order, Level A): Content should follow a logical order when tabbing through the page.
- 2.1.1 (Keyboard, Level A): All site functions should work with only a keyboard.
- 2.4.7 (Focus Visible, Level AA): People should see which element is active at all times.
- 2.4.11 & 2.4.12 (Focus Not Obscured, WCAG 2.2, Levels AA & AAA): The focused element has to remain visible instead of scrolling off-screen.
Meeting these criteria helps make sure your site is accessible and much easier to navigate.

Simple Tips to Get It Right
- Use the DOM Order: Write your HTML in the order you want people to move through the page. That way, you don’t have to force things with unique attributes.
- Use Correct Elements: If you have something clickable, make it a <button> or <a>. This makes it automatically focusable without extra work.
- Be Careful With tabindex: tabindex= “0” can help include an element in the natural focus sequence. tabindex= “-1” keeps something out of the normal flow but still lets you focus there with scripts. High or random values can create chaos.
- Manage Modals Properly: When a modal pops up, focus should jump into it. People should be able to tab around inside and close it without getting stuck. Once it’s closed, the focus should return to the element that opened it.
- Keep Focus Visible: If your brand style doesn’t match the default outline, customize it with a high-contrast border or box-shadow. Whatever you do, make sure people can still see where they are on the page.
Testing and Tweaking Your Site
1. Manual Testing – Put your mouse away and try tabbing through the page. Ask yourself if the order makes sense and if you can reach everything you need.
2. Browser Tools – Chrome DevTools and Firefox Accessibility Inspector can show you how each element appears in the accessibility tree, which can help you spot weird focus flows.
3. Automated Tests – Tools like WAVE and Lighthouse are helpful for flagging fundamental problems, though they won’t catch everything.
4. Real Users – If possible, ask people who rely on keyboard navigation to test your site. They’ll be the quickest to notice focus issues you might miss.
Wrapping Up

Focus order might sound like a small detail, but it’s a massive deal for those who rely on the keyboard to get around. A logical, precise tab sequence helps keep your site user-friendly, no matter who’s visiting. If you’re worried about your site’s accessibility, it’s never too late to run an audit or refresh your code.

Need extra help? Contact 216digital, where we specialize in creating accessible websites that work well for everyone. Whether you just need a quick review or a complete accessibility plan, we’re here to make your site feel welcoming for all kinds of users.
Greg McNeil

March 19, 2025

How-to Guides, WCAG Compliance

focus order, WCAG, WCAG conformance, web developers, web development
A Guide to Accessible Table Design & Development
Once upon a time, table design was web design. Before the elegance of CSS Grid or the flexibility of Flexbox, we built entire sites with <table>, <tr>, and <td> like it was second nature. They were the backbone of layout — the duct tape holding the early web together. But as web development matured, we traded layout tables for cleaner, more semantic code. Still, tables remain essential — not for layout, but for what they were truly meant to do: present data.

So, where do tables fit into modern, accessible web design? When are they appropriate, and how do we use them in a way that supports users of all abilities, including those using screen readers or keyboard navigation?

In this guide, revisit table design through a modern lens — not to reminisce about the old days of spacer GIFs and nested rows, but to examine how to use tables the right way today. Whether you’re structuring tabular data or dealing with legacy layouts, we’ll walk through practical techniques for designing and coding tables that are both functional and inclusive.

Understanding Tables in Web Design

Tables still serve a clear purpose in today’s web — when used thoughtfully. But there’s a key distinction: data tables are for presenting information, and layout tables… well, those belong in the same drawer as Netscape hacks and the blink tag. How you use them matters, especially for folks navigating with a screen reader or keyboard.

Understanding the difference is the first step toward solid, accessible table design that doesn’t leave users behind.

Data Tables

Need to show structured data like schedules, product comparisons, or sales reports? That’s what data tables were born to do. When used well, they make complex info digestible — like a well-organized spreadsheet that doesn’t make you want to flip your monitor.

Making Data Tables Accessible

Start with semantic HTML — <th> for headers, <caption> for context, and group rows and columns meaningfully. These tags are like orientation tools for assistive tech — they help users actually understand the structure, not just hear a blob of words.

Reading order is your next frontier. If your table reads like it was assembled after three espressos and a deadline, it’s time to regroup. Make sure users can follow the flow with no surprises.

And if you’re knee-deep in rowspans and colspans, it’s worth pausing to ask: “Is this actually helping, or am I just flexing?” Clean table design helps avoid this entirely.

Layout Tables

Let’s talk about the fossil in the room: layout tables. We all used them. Some of us even nested them. Some of us still wake up in cold sweats because of them.

Why They Were Used

Back in the day, if you wanted a three-column layout, you reached for a table. Pixel-perfect footer? Table. It was the best option we had — right up until CSS knocked politely and said, “I got this.”

Why It’s Time to Move On

CSS changed the game. Layout tables now clutter your markup, confuse screen readers, and break responsiveness faster than you can say “media query.” The result? A tangled mess that’s hard to debug and harder to maintain.

Golden rule: Tables for data. CSS for layout. Break this rule only under duress (or for archaeological purposes).

If you must touch layout tables, think of it less as designing a layout and more as preserving legibility. It’s a survival-style form of table design.

When You Have to Use Layout Tables

Sometimes, you inherit legacy code that’s more delicate than a house of cards. Or you’re working with a CMS that still thinks it’s 2003. When you’re stuck, the goal becomes minimizing the chaos.

Best Practices for Using Layout Tables (Responsibly)
- Skip semantic elements: Leave <th> and <caption> out. They’ll only mislead screen readers.
- Use role= "presentation": This politely tells assistive tech, “Nothing to see here — just visuals.”
- Keep content order logical: It might look fine, but hit the tab or turn on a screen reader. If it reads like a jigsaw puzzle, rework it.
- Make it responsive — sort of: You’re already doing something frowned upon. At least don’t let it collapse on mobile.
CSS to the Rescue

Need flexible, responsive, accessible layouts? CSS has your back. You’ve got two powerhouse options ready to roll.

CSS Grid Layout

CSS Grid is built for complex, two-dimensional layouts. It gives you surgical control over rows and columns without diving into the <td> abyss.

Heads-up: Keep your DOM order consistent with your visual order. Otherwise, assistive tech users will be piecing together your layout like a mystery novel.

CSS Flexbox

Flexbox handles one-dimensional layouts like a champ. Think nav bars, form groups, toolbars — anything that lines up in a row or column.

Just remember, Flexbox can reorder your layout visually, but screen readers still follow the source order. Rearranging things for aesthetics? Fine. Just don’t confuse your users while you’re at it.

Both of these tools help prevent misuse of tables and support better table design principles by removing the temptation to force non-tabular content into table markup.

Follow the Principles, Not Just the Code

Accessibility isn’t about ticking boxes — it’s about designing with real people in mind. Think about how someone actually experiences your content. No mouse. No visuals. Just structure, clarity, and flow.

If someone is using a screen reader, keyboard navigation, or sip-and-puff device, your clean CSS layout means nothing if your content order is a mess. Great table design considers these experiences from the start.

Key Guidelines from WCAG to Keep in Mind:
- Info and Relationships (1.3.1): Use markup to show how data connects. Don’t rely on appearance alone.
- Meaningful Sequence (1.3.2): Your content should flow in a way that makes sense, both visually and in the code.
Quick Recap: Best Practices
- Use tables only for tabular data — not layout, not nostalgia
- Mark up data tables semantically — <th>, <caption>, proper scope
- Use CSS (Grid or Flexbox) for layout — always
- Only use layout tables when you absolutely have no other option
- If you must use layout tables, strip out semantics and add role=" presentation"
- Don’t rely on automated tools alone — test with real assistive tech
Final Thoughts

The web’s grown a lot since the days of spacer GIFs and table-based layouts — and thankfully, so have our tools. We can build cleaner, more flexible, more inclusive sites with far less hassle than we could a decade ago.

So let’s do that. Use tables where they belong — to present data. Embrace modern CSS for everything else. And always remember: building for accessibility doesn’t slow you down. It just makes your work better.

And if you’re ever elbow-deep in a legacy layout table with seven levels of nested <tr>, know this: someone out there gets it. And they’re probably muttering “never again” right along with you — while dreaming of cleaner table design.
Greg McNeil

March 18, 2025

How-to Guides

Data tables, How-to, table design, web developers, web development

Why Accessibility Isn’t “One and Done”

The Legal Stakes: Second-Time Lawsuits Are Surging

Training Makes You Proactive, Not Dependent

It’s Not Just the ADA Anymore

Why Training Costs Less (and Does More) Than You Think

What 216digital’s Training Really Looks Like

Who Needs to Be Trained?

A Human Approach That Actually Sticks

The Bottom Line: Keep What You’ve Built

Why Data Privacy and Accessibility Align

A Quick Primer on U.S. Privacy Rules

What Accessibility Means Online

Where the Two Worlds Meet

Four Places Trust Can Break

1. Consent & Cookie Pop-Ups: The Front Door of Trust

2. Forms and Checkout

3. Analytics and Tracking

4. Content Files

Building a Cross-Team Trust Framework

Action Plan in Seven Steps

Measuring Success

Final Thoughts

Meet the Guidelines: WCAG 3.3.1 to 3.3.4

Labeling: The First Step Toward Clarity

Inline Error Messaging: Real-Time Feedback That Actually Helps

Don’t Skip aria-describedby

About Placeholders: Don’t Rely on Them Alone

Smart Form Validation

Crafting Helpful, Accessible Error Messages

Test It Like You Mean It

Keep Moving Toward More Accessible Forms

What the CCPA Introduced to U.S. Businesses

A Ripple Effect Beyond California

The GDPR: Setting the Global Standard

Core GDPR Requirements:

GDPR vs. CCPA: Two Paths, One Direction

Who’s Affected?

Consumer Rights

Consent Models

A Growing Patchwork of U.S. Laws

What You Can Do Now

1. Map Your Data

2. Strengthen Your Privacy Policy

3. Build in Flexibility

4. Respect User Rights

5. Lead with Transparency

Final Thoughts

Unpacking aria-describedby

Why It’s Important

When Should You Use aria-describedby?

When Not to Use It

Code Walkthroughs: Real-World Examples

Form Fields

Password Requirements

Error Messages

Multiple Descriptions

Buttons

Destructive Action Explanation

Dialogs and Modals

Accessible Dialog

Tooltips and Live Regions

Accessible Tooltip

Status Messages

Common Mistakes to Avoid

Best Practices for Effective Implementation

Beyond the Code: Organizational Tips

Accessible Descriptions, Better UX

Why Accessibility Matters in E-Commerce

Making Your Shopping Cart Work for Everyone

Add Clear Labels (Yes, Even for Buttons)

Let People Update Cart Items Without Guesswork

Show Helpful Feedback When Things Go Wrong

Shipping Forms That Are Easy to Use (and Easy to Navigate)

Use Straightforward, Consistent Labels

Make Sure Users Can Tab Through Fields Logically

Show Errors Clearly and Offer Suggestions

Designing a Payment Flow That’s Smooth and Inclusive

Offer More Than One Way to Pay

If You Use CAPTCHAs, Make Them Accessible

Choose Accessible Payment Gateways

Don’t Skip `aria-describedby`

Why `<button>` and not `<div>` or `<a>`?

Option 1: Native HTML with `<details>` and `<summary>`