DubBlog

Meeting the DOJ Title II Compliance: Don’t Forget Your Accessibility Policy

DubBot — Tue, 10 Nov 2026 00:00:00 +0000

For state and local governments working toward DOJ Title II compliance, much of the attention is on websites, PDFs, mobile apps, and WCAG testing.

But another piece belongs on your compliance roadmap. And that’s your organization’s web accessibility policy.

In the DOJ’s First Steps resource, one of its non-mandatory steps toward compliance is to create web and mobile accessibility policies.

I want to stop here for a minute to share a critical issue in meeting Title II compliance and to thank Dax Castro (LinkedIn)for bringing it into the ADA / Title II compliance conversation.

Here is a direct quote from his article titled What No One’s Telling You About Meeting the Title II Deadline (LinkedIn), published on Oct. 30, 2026 on LinkedIn.

But there’s another question that deserves just as much attention: What is your organization publishing today?

Because while you’re working through last year’s documents, someone is creating next month’s accessibility problems. A department is updating a form. A designer is exporting a report. Someone is posting a video, purchasing a new platform, or uploading a document from an outside vendor.

I’m not going to paraphrase his entire article, but I do recommend you give it a read, as well as the comments.

I do, however, want to point out why I felt it was important to include the message from his article in this blog post.

The DOJ deadline did not create a cease-and-desist order for updating or creating new content on your website. Those activities never stop. Daily updates are required, new class schedules must be posted, new employee profiles need to be added, and there are the daily / weekly maintenance items that are part of running a website.

But how people in your organization are currently creating that web content is a direct reflection of your organization’s web accessibility policy or the absence of one.

The message in Mr. Castro’s article can be directly related to having a web accessibility policy in place. As you move through your compliance activities, make sure your web accessibility policy works in tandem with those activities and gets updated as your accessibility work reveals new processes, workflows, and responsibilities.

And if you don’t have a policy currently in place, there’s no time like the present.

Now, back to the topic at hand.

What is a Web Accessibility Policy?

A web accessibility policy is a clear, internal framework that spells out your organization’s commitment to making its digital content and services accessible to everyone.

Why Do You Need a Web Accessibility Policy?

An effective accessibility policy does more than just document an organization’s intentions. It establishes the strategic foundation for making digital accessibility an ongoing organizational priority. It outlines the standards that guide accessibility efforts, clarifies team roles and accountability, and sets expectations for meeting legal requirements.

What Should You Include in Your Web Accessibility Policy?

The World Wide Web Consortium (W3C) recommends defining your accessibility standard and conformance level, establishing the policy’s scope, setting measurable milestones, addressing third-party content, and creating processes to monitor, review, and collect user feedback.

A strong web accessibility policy should include the answers to these, and other, critical questions:

What needs to be accessible?

Public websites and web apps, including marketing sites, product pages, and login-gated experiences like dashboards, portals, and checkout flows.
Mobile apps and any embedded or third-party tools your users engage with, such as chat widgets, scheduling tools, payment forms, and cookie banners.
Subdomains, microsites, campaign landing pages, and legacy pages that are still live. These are the most commonly forgotten elements.
Archived content. Best practices say to define the archive date, provide an email address and phone number, and offer an accessible alternative on request.

Don’t forget to include specific content types. Some examples are:

Text should include proper headings, lists, tables, links, and reading order.
Images, icons, and charts should include meaningful ALT text or text alternatives.
Video and audio need captions, transcripts, and audio descriptions where needed.
Downloadable documents such as PDFs, Word files, slide decks, and spreadsheets.
Forms, error messages, and interactive components like menus, modals, carousels, and custom widgets.
Dynamic content, including notifications and live updates.

Which accessibility standard are we following?

For public entities adhering to the DOJ Title II rule, the required technical standard is WCAG 2.1 Level AA. The current compliance deadlines are April 26, 2027, for public entities serving populations of 50,000 or more, and April 26, 2028, for smaller entities and special district governments.

Who’s Responsible for Creating and Maintaining Website Accessibility?

Everyone who contributes to your website has a role in making it accessible, but your organization is ultimately responsible for keeping accessibility a priority.

Website accessibility isn't a task that belongs exclusively to your developers or accessibility compliance officer. It's an ongoing organizational commitment that involves leadership, designers, developers, content creators, procurement teams, and anyone who contributes to or makes decisions affecting your digital presence.

The key is making sure everyone understands their responsibilities and that accessibility is built into your organization's processes, not treated as a final checkpoint before something goes live.

Think about ownership across your organization like this:

The Ultimate Accountability

Your organization is ultimately responsible for the accessibility of its entire digital experience, regardless of who creates, manages, or maintains the content.

That includes everything from your own website content to third-party applications, embedded tools, and other digital services. You can outsource development, purchase software, or rely on vendors to provide accessible products, but you can't outsource accountability.

As highlighted in Third-Party Tools, First-Party Responsibility: When Your Vendor Isn't Listening, your organization remains accountable for accessibility issues within its digital experience, even when the underlying code is managed by a third-party vendor.

Your organization should set clear accessibility expectations, assign ownership, provide training and resources, and create processes to identify and address accessibility barriers.

Designers

Designers influence accessibility long before a website or application is developed. Their decisions determine how information is presented, what colors are used, how users navigate an interface, and how easily people with different abilities can interact with digital content.

Accessibility shouldn't be something designers are asked to fix after a design is complete. It should be part of the creative process from the beginning.

Developers

Developers are responsible for translating accessible designs into functional, usable digital experiences. Even a well-designed interface can introduce accessibility barriers if it's not implemented correctly.

Developers also play an important role in maintaining accessibility as websites evolve. New features, design changes, and code updates should be evaluated for accessibility rather than assuming previously accessible functionality will remain that way.

Content Creators and Editors

Anyone who writes, uploads, or publishes website content has a responsibility to make that content accessible.

This includes marketing teams, communications professionals, department editors, and anyone with publishing privileges.

Your organization should provide content creators with accessibility training, publishing guidelines, and tools to help them identify potential issues before content goes live.

Procurement and Third-Party Vendors

Your website's accessibility doesn't stop with the content and technology your organization creates internally.

Third-party applications, embedded widgets, payment platforms, scheduling tools, video players, and other vendor-provided services can all introduce accessibility barriers.

That's why procurement teams need to be part of the accessibility conversation.

Requiring an Accessibility Conformance Report (ACR) will provide valuable information to help organizations evaluate a product's conformance and make informed purchasing decisions.

Organizations should evaluate a vendor’s accessibility practices and establish clear accessibility requirements before selecting or purchasing a product. These expectations should be documented in the RFP and built into contract terms so accessibility is considered part of the procurement decision.

How will accessibility be monitored and maintained?

Your accessibility policy should outline the processes and practices your organization uses to monitor, maintain, and continually improve digital accessibility. This includes establishing a schedule for regular automated scans and manual accessibility audits, identifying how issues will be documented, prioritized, and remediated, and assigning responsibility for tracking progress.

Your policy should provide contact information or a process outline for each of your accessibility feedback channels. Each channel must have a designated owner and a documented process for responding to reported issues. Remember, not everyone communicates the same way, so offering varying feedback channels that accommodate different needs and preferences goes a long way in helping people help you.

Your policy should also address ongoing staff training, accessibility reviews during website updates and new content development, and opportunities to incorporate user feedback.

By defining these expectations, your policy creates a framework for keeping accessibility efforts consistent, measurable, and sustainable.

Why Finalize the Policy Now?

Without documented ownership, publishing requirements, procurement standards, testing processes, and review cycles, you risk remediating just enough to meet the DOJ Title II deadline without establishing accessibility practices that will keep you in compliance.

Your accessibility policy is what will prevent you from repeating that cycle.

This is especially important as organizations work toward the DOJ Title II compliance deadline. While the pressure to identify and remediate accessibility issues is understandable, focusing exclusively on meeting the deadline can create new accessibility debt if the underlying processes that allow those issues to happen remain unchanged.

Don't let the rush to meet the DOJ Title II deadline create new accessibility issues. Your accessibility policy should do more than document your current efforts. It should establish the framework that keeps accessibility a priority long after the deadline has passed.

Resources

A human author creates the DubBlog posts. The AI tools Gemini and ChatGPT are sometimes used to brainstorm subject ideas, generate blog post outlines, and rephrase certain portions of the content. Our marketing team carefully reviews all final drafts for accuracy and authenticity. The opinions and perspectives expressed remain the sole responsibility of the human author.

A First-Timer's Take on Digital Collegium 2026: Pittsburgh, New Perspectives, and Great Connections

DubBot — Thu, 05 Nov 2026 00:00:00 +0000

From left to right: Luke Bachelor, Blaine Herman, Penny Kronz, Marcella Colavecchio, Greg Glowaski.

I've attended my fair share of conferences throughout my career, but Digital Collegium 2026 was a first for me in more ways than one.

Most of my previous conference experiences have been centered around engineering and technology, so heading to Pittsburgh with DubBot meant approaching things through a different lens. This time, I was focused on building relationships, meeting the people behind the work, and connecting with the higher education community.

I went into the week with an open mind, a pocket full of curiosity, and the hope of making meaningful connections. It was also my first time in Pittsburgh, so I was excited to explore a new city along the way!

A Warm Welcome (and a Little Friendly Competition)

From the moment the conference got underway, the energy was buzzing. Between the sessions, vendor area, and conversations happening around every corner, there was no shortage of activity.

At the DubBot booth, we put our own spin on the classic dice game Left, Right, Center. What started as a fun way to bring people together quickly turned into some friendly competition. It was a great excuse to step away from the usual conference conversations, share a few laughs, and get to know each other.

DubBot custom pen with several Dubby DubBloons and a set of
Left, Right, and Center dice.

What stood out most was the genuine sense of community. Everyone was welcoming and eager to stop by and share their experiences, whether we connected between sessions or got to know one another outside the conference. My first Karaoke Plane at Tequila Cowboy was a perfect example. And, as it turns out, higher ed has some seriously talented karaoke singers!

DubBot’s own Luke Batchelor performing at the annual
Karaoke Plane at Tequila Cowboy.

A Little Sunshine in Pittsburgh

Despite Pittsburgh's reputation for gray skies, we were greeted with pristine, blue skies. I'd like to think I brought a little of that Texas sunshine with me from Austin.

One of the things I appreciated most about Pittsburgh was how walkable it was. Coming from a car-centric city like Austin, it was refreshing to explore neighborhoods filled with small businesses, restaurants, and residential streets all woven together.

Naturally, we made time for some good food! We explored downtown's Market Square, tried the famous Primanti's sandwiches, enjoyed dinner at Kaya, and ventured up to Mount Washington for an unforgettable dining experience at Otaru. Another personal favorite was a fantastic lunch at People's Indian Restaurant in Bloomfield.

Historic Market Square in downtown Pittsburgh.

Nightscape of the Monongahela River and the Fort Pitt Bridge.

We also visited the Heinz History Center, where we explored all six floors in pursuit of a coveted pickle pin.

Marcella showing off her Heinz Pickle pin.

I especially loved seeing original pieces from the set of Mister Rogers' Neighborhood, including his iconic sweater.

Iconic artifacts from the Mr. Roger’s Neighborhood.

Between the food, neighborhoods, sunshine, and a few memorable karaoke performances (yes, there's video evidence), Pittsburgh really won me over.

Beyond the Sessions: Making Accessibility Approachable

One of my biggest takeaways from Digital Collegium was how much thought higher education professionals are putting into making their digital experiences more accessible.

I want to give a very special shoutout to my colleague, Penny Kronz, for her presentation, Comprehensive Guide to Web Accessibility Testing and Best Practices!

Left to right: Penny Kronz and Joanie Chembars.

One of the things I appreciate most about Penny is her ability to take something as complex as web accessibility and break it down in a way that's approachable and easy to understand.

Accessibility and website governance can get technical quickly, and sometimes the platforms designed to help make things feel even more complicated. That's something I really value about Penny and our team at DubBot. We believe accessibility doesn't have to be intimidating, and we work hard to make it easier for people to understand what needs attention and how to move forward.

Penny's presentation was a great example of that philosophy in action. She shared practical approaches to accessibility testing, from keyboard navigation and screen readers to color contrast and accessible forms. One important reminder was that automated testing is only part of the picture. Understanding how people actually experience a website also requires human judgment.

Congratulations, Penny! We're lucky to have someone who makes such an important topic feel approachable.

PDFs, PDFs, and More PDFs!

If there was one topic I kept hearing about throughout the conference, it was PDFs.

Abbey Allen and Josh Leigh from the University of Utah presented Optimizing PDF Accessibility and Findability: The LAST Process for Web Content Management, introducing a thoughtful approach to managing large PDF inventories.

Their LAST framework stands for Locate, Assess, Stabilize, and Transport , encouraging institutions to evaluate what content to keep, remediate, convert to HTML, or archive.

One of my favorite takeaways was a simple question: Does this really need to be a PDF?

Sometimes making content more accessible isn't about fixing the format it's currently in. It's about rethinking how that information should be presented in the first place.

And this is where things get especially exciting for us at DubBot!

PDF accessibility and management are areas we're actively exploring as part of our product roadmap. We're thinking beyond identifying accessibility issues to how we can better help our clients prioritize remediation and make informed decisions about which documents to convert, archive, or remove.

Hearing these challenges echoed throughout the conference reinforced something I value about our approach at DubBot: we listen to the people doing the work and want to build solutions that make accessibility and content governance less overwhelming.

From Screens to Real Life

Left, front to back: Greg, Joanie, Marcella. Right, front to back: Luke, Blaine, Penny.

One of the week's highlights had very little to do with conference sessions. I finally met my DubBot colleagues in person for the first time!

As a remote company, we spend plenty of time collaborating through screens, so I was really looking forward to spending a few days together.

Our sales team, Blaine Herman, Greg Glowaski, and Luke Batchelor, joined Penny Kronz and Joanie Chembars from Client Support. It was my first time meeting everyone face-to-face, and what surprised me most was how natural it felt. We picked up right where we left off, only this time without having to unmute ourselves.

One of my favorite moments was our dinner at Otaru, sitting together somewhere quiet, overlooking the Pittsburgh skyline, and enjoying a gorgeous meal. Those precious moments away from the busy conference floor are where the best connections happen.

Of course, there was plenty of fun, too. Between the dice games, karaoke adventures, and glow stick jewelry I made for everyone, we shared a lot of laughs throughout the week.

If there's one thing the experience reinforced for me, it's that we're human first .

I see that reflected in the way our team works together and the relationships we build with our clients. Behind DubBot are real people who genuinely care about supporting one another and the people who use our platform.

Until Next Time, Digital Collegium!

The Monongahela River and Fort Pitt Bridge.

Looking back on my first Digital Collegium experience, what stands out most isn't just the sessions or the beautiful city we got to explore.

It's the people.

From meeting customers and making new connections to finally spending time with my colleagues in person, the week reminded me why relationships matter so much in the work we do.

If you're thinking about attending Digital Collegium for the first time, my advice is simple: show up with an open mind. This community is full of friendly, engaging people who are genuinely excited to share ideas and learn from one another.

I'm heading home with new perspectives, great memories, and an even greater appreciation for the people who make this community what it is.

Thanks for the warm welcome, Pittsburgh and Digital Collegium. I hope our paths cross again soon!

Getting More From Custom Labels: Smarter Page Sets in DubBot

DubBot — Tue, 03 Nov 2026 00:00:00 +0000

If you're managing a large collection of websites in DubBot, better organization can make a big difference. That’s why we brought you Custom Labels. Those customizable tags that help you organize and filter your Sites, Page Sets, and Tasks in ways that make sense for your organization.

Now, Custom Labels can do more than help you sort and filter your Sites.

You can now use Custom Labels to build Page Sets and define which Sites to include based on the label(s) you apply, making it easier to organize and manage your content at scale.

Quick Review: A Smarter Way to Organize Sites

Custom Labels let you group Sites according to the way your organization actually works.

For example, a university could label Sites by academic department, student services, administration, or athletics. An agency might organize them by division, region, or product line.

Once applied, those labels make it easier to filter Site listings and find the websites you're looking for.

Label-based Page Sets: How They Work

With this latest update, you can use Site labels to create a Page Set that dynamically selects and adds individual websites.

For example, if you create a Page Set configured to include Sites with a label titled Weekly Manual Review, all Sites with that label will automatically be included in your new Page Set. No more manually adding the Sites to new Page Sets.

Bringing You More Strategic Oversight

The real value of Custom Labels isn't just organization. When labels and Page Sets work together, you spend less time managing lists and more time focusing on website quality, accessibility, and web governance.

It's an organizational strategy that doesn’t just keep your website organized, it makes managing growth significantly easier.

Resources

Is Your Website Relying on Color Alone?

DubBot — Thu, 29 Oct 2026 00:00:00 +0000

One of the easiest accessibility mistakes to make, and one that I think is often overlooked, is relying on color to communicate something important. It might be a red outline around a form field, a blue link in a paragraph, or a chart that uses different colors to distinguish data. These choices may look perfectly clear to you, but not everyone sees color the same way.

The good news? Fixing these issues is pretty straightforward.

WCAG Success Criterion 1.4.1: Use of Color requires that color not be the only visual way to convey information, indicate an action, elicit a response, or distinguish an element. In other words, color can add meaning, but it shouldn't do all the work.

Who Does Use of Color Affect?

People with color vision deficiencies may have difficulty distinguishing certain colors, particularly red and green. People with low vision can also struggle with color distinctions and may lose those distinctions when viewing content in gray scale or using display filters.

Note: This is not just about accommodating a particular group. When a form doesn't explain an error or a chart doesn't clearly identify its data, the result can be a confusing experience for everyone.

What Does a Color-Only Accessibility Issue Look Like?

Start by looking at elements on your website where users must recognize a color difference to understand what's happening.

Then ask yourself this: If someone couldn't distinguish these colors, would they still understand the information or action to take?

If your answer is no, you may have a color-only accessibility issue.

Here are four common elements where this issue may occur.

LinksLinks appear in blue within a paragraph, but there's no underline or other visual indicator to distinguish them from surrounding text.

Form ErrorsA field turns red when someone makes a mistake, but there's no error message explaining what went wrong.

Required Fields
Required fields have red labels, but no asterisk or Required text to identify them.

Charts and Graphs
Data series use different colors (sometimes very similar colors, which causes issues too) but have no labels, patterns, or other ways to distinguish one data set from another.

How Do You Fix Color-Only Issues?

The solution is very simple. Choose and use accessible color palettes, ensure proper contrast, then add another visual indicator that communicates the same information.

For example:

LinksAdd an underline so links stand out from adjacent text, even when their color isn't distinguishable.

Form ErrorsProvide an accessible error message with instructions on how to fix the error. Place the message in close proximity to the form field, such as above the field or to the right of the field.

Required FieldsAdd an asterisk or a visible Required label (or both). Explain the asterisk convention at the top of the form, ahead of any form fields.

Charts and GraphsUse direct labels, distinct line styles, shapes, or patterns so people can identify data series without relying on color alone.

Status IndicatorsUse icons or text alongside color indicators. For example, pair green for Success with a checkmark and red for Failed with an X.

One Important Distinction

Color contrast and use of color are two different accessibility requirements, but they work closely together.

Sufficient contrast helps people distinguish foreground elements from their backgrounds. Use of color addresses whether color is the only visual cue conveying information.

A design can meet contrast requirements and still have a use-of-color issue.

Make Testing for Use of Color Part of Your Accessibility Strategy

When reviewing a website, check links, forms, charts, status indicators, and interactive elements. Determine if each element can communicate its purpose without depending on color alone.

Color should support and / or reinforce meaning, but not be the only way to communicate it.

Adding a second visual cue is a simple change that makes a big difference in how people understand and use your website.

Small, intentional improvements can remove real barriers for users while helping you build accessibility into your everyday workflows.

Resources

Use of Color
Understanding SC 1.4.1 Use of Color (Level A)
Color Only LinkedIn post from IxDF - Interaction Design Foundation

Why the Right Conference Makes a Difference

DubBot — Thu, 22 Oct 2026 00:00:00 +0000

As the 2026 Digital Collegium Annual Conference wrapped up yesterday, I found myself thinking about other conferences I’ve attended over the years, specifically the ones I got the most from and looked forward to attending again.

It occurred to me that topic- or subject-based conferences certainly have their place and can be valuable, but there’s something about being in a room full of people who swim in the same waters as you do. ~ Solving the right problem: Why web governance fails when it starts with control, Danny Collier (LinkedIn).

Community-focused conferences bring together professionals who share similar goals, tackle familiar challenges, and share the realities of your day-to-day work.

That shared experience creates opportunities to learn from one another, discover practical solutions, and make connections that last long after the conference ends.

Benefit From People Who Get It

One of the biggest benefits of attending a community-focused conference is realizing you’re not the only one facing a particular challenge.

Maybe you’re struggling to get buy-in for a new initiative, trying to make limited resources stretch further, or figuring out how to adapt to changing technology. Chances are, someone else in your specific field has faced a similar situation.

A good community-focused conference gives you a chance to share and compare lived experiences, talk about different approaches, and learn what worked and what didn’t. Sometimes, hearing how another organization solved a problem will spark an idea you hadn’t considered. Other times, learning what didn’t work saves you from making the same mistakes.

These conversations offer something you won’t always find in a generalized topic-based webinar or professional development gathering. And that is honest, practical insight from people who don't just understand your environment but live in that same environment themselves.

Take Home Action Items, Not Just Cool Swag

It’s easy to leave a conference energized by new ideas. The real value comes when you can put those ideas into practice. Community-focused events often focus on the issues, tools, strategies, and trends that matter most to your profession. Instead of sifting through broad advice to find what applies to your work, you can focus on insights that are relevant to your organization and the people you serve.

And you don’t have to overhaul your entire approach to make attending worthwhile. As the Digital Collegium Annual Conference event chair, Tom Wojciechowski (LinkedIn) suggests in a recent interview with Link Journal, look for one or two key takeaways you can bring back to your organization and put into action right away.

That’s a useful way to approach any conference. Pay attention to the ideas that address a current challenge, offer a fresh perspective, or give you practical next steps. A single idea that improves your work can make the time and money spent attending worthwhile.

Go Beyond Networking

Networking can sometimes feel awkward when you’re making small talk with people whose work may be similar, but whose organizational culture, resources, and challenges have little in common with yours.

Community-focused conferences make it easier to break the ice because you already have something in common.

You might meet someone who manages a team like yours, works with the same technology, or has found a creative solution to a problem you’re still trying to solve. Those connections can become valuable sounding boards, sources of advice, and professional relationships that continue well beyond the event.

And the benefits aren't limited to scheduled networking sessions. Conversations over lunch, between presentations, or at an informal social event can be just as valuable as the sessions themselves.

Finding the Value

And remember. You don't have to return from a conference with a notebook full of ideas or dozens of new contacts to make it worthwhile.

Start with a few simple goals like:

finding a new approach to a current challenge, learning from someone else's experience, and connecting with a few people who understand how you work or
try attending a session outside your usual area of expertise, too. You might discover an unexpected connection or an idea you can adapt to your own role.

The real value of a community-focused conference isn't simply what you learn but what you do with it. One conversation might change how you approach a problem. One new connection might become a trusted resource. One idea might help your team work smarter or see a familiar challenge differently.

You leave with more than notes, business cards, and a bag of swag. You leave with fresh perspectives, practical ideas, and hopefully, new friends and colleagues who understand your work and can help you move it forward.

And you’ll have something to look forward to next year. 😉

End-to-End Accessibility Testing: Going Beyond the Page

DubBot — Tue, 20 Oct 2026 00:00:00 +0000

A website can pass automated and manual accessibility checks and still fail someone trying to accomplish a task.

A form might have accessible labels. A button might work with a keyboard. Every page might pass an accessibility audit. But if someone tries to register for an event, apply for a job, or make a purchase and can’t complete the task, those individual accessible components aren’t working together to create an accessible experience.

That’s where end-to-end (E2E) accessibility testing comes in.

What Is End-to-End Accessibility Testing?

I first heard the term end-to-end testing during the DigiCol Accessibility Summit in July. I was already familiar with concepts like user journey, journey mapping, and critical path from my work in UX, so the idea of end-to-end testing wasn’t entirely new to me. What was new was applying that way of thinking to accessibility testing.

There are various ways to conduct accessibility testing, and each has a different level of focus:

Automated testing identifies common, detectable accessibility issues, such as missing form labels or insufficient color contrast.
Page-level manual testing examines how people interact with an individual page using keyboards, screen readers, and other assistive technologies.
Component testing evaluates individual interface elements, such as navigation, buttons, or drop-down menus.
End-to-end testing brings these levels of focus together to evaluate the entire user journey from start to finish.

Each level of focus is valuable in its own right and should be part of your comprehensive, ongoing accessibility strategy. But end-to-end testing shifts the focus from whether individual pages and components are accessible to whether they work together to help someone accomplish a real goal.

Users Have Goals, Not Test Cases

Traditional accessibility testing often gets broken into testing the navigation, testing the form, testing the table, etc.

Those are all very necessary, but people don't come to your website to test the navigation or validate your forms. They come with a purpose and a goal.

They come to your website to register for an event, find information, submit an application, or complete a transaction. Your accessibility testing should follow the user’s path required to accomplish their goal, not just your website's structure.

Scenarios can help. An end-to-end testing scenario helps you evaluate whether someone can move through an entire process, recover from any mistakes, and receive confirmation that the task is complete. This is testing real-world context, not just whether an interaction works.

Build Your Scenarios Around Tasks, not Components

Start with a user goal and build a scenario around the path a person needs to take to accomplish it. First, test the happy path, the expected outcome from beginning to end. This ensures all components and interactions work together. Then test errors and alternate paths, things like missing required information, invalid entries, proper tab order, and error recovery, to identify issues that could prevent someone from reaching their goal.

For example, test the user path for registering for an event.

First, identify your user. In this example, your user navigates with a keyboard and screen reader and wants to register for an upcoming event.

Follow the required steps, confirming the user can:

Find the event through navigation, search, or a listing.
Identify the event's title, date, time, location, and registration requirements.
Activate the registration button and understand the resulting page or dialog.
Navigate the form in a logical order, ensure focus is visible, understand each field, and enter the required information.
Identify required fields and submit the form without a mouse.
Recognize validation errors, understand what needs correcting, and return to the affected fields.
Complete any additional steps, such as agreeing to terms or choosing a session.
Submit the registration and receive a screen-reader-accessible confirmation with the relevant event details.

Next, discover what happens when a session is full, a required field is missed, or the submission takes longer than expected.

Scenarios You Should Consider

Start with the scenarios that matter most to your users. Prioritize based on user needs, business impact, and the consequences of an inaccessible experience. Here are a few suggestions to help get you started:

Find InformationSearch for a topic and locate a specific answer.

Create an AccountRegister, verify an email address, and sign in.

Recover AccessReset a password, return to the account, and receive confirmation.

Complete a PurchaseFind a product, add it to the cart, check out, and receive confirmation.

Submit an ApplicationFind an opportunity, complete the form, upload documents, submit, and receive confirmation.

Make an AppointmentSelect a date, an available time, add a subject or note, and receive confirmation.

Contact SupportFind contact options, submit a request, and verify confirmation.

Manage an AccountUpdate personal information, save changes, and confirm the update.

Making The Connection

Automated testing can identify individual accessibility issues. Manual testing can investigate specific user experiences. End-to-end testing connects the two, evaluating accessibility in the context of the user’s actual goal.

That connection matters. It’s where accessibility testing delivers its greatest value: ensuring everyone has the same opportunity to use your website, complete their tasks, and achieve their goals.

Resources

Celebrate NDEAM: Build Accessibility Into Everyday Work

DubBot — Thu, 15 Oct 2026 00:00:00 +0000

October is National Disability Employment Awareness Month (NDEAM), a time to recognize the contributions of workers with disabilities and promote accessible workplaces. It’s also a good reminder that accessibility isn’t just the responsibility of a few dedicated people. It’s everyone’s responsibility.

More often than not, organizations treat accessibility as a specialized skill set owned by a handful of experts, while everyone else works around it. But that model doesn’t scale. No matter how knowledgeable your accessibility team is, they can’t be in every meeting, review every purchase, write every piece of content, or influence every design decision.

Accessibility isn’t created by a handful of experts. It’s influenced by hundreds of everyday decisions made across an organization, from the technology you buy to the content you create to the experiences you design.

The goal isn’t to turn everyone into an accessibility expert. It’s to build enough shared insight that people recognize when their decisions have accessibility implications, and the knowledge to know what to do next.

Accessibility Awareness at Scale is What Changes an Organization

Think about it.

Designers choose color and layout, influencing whether color contrast is sufficient and interfaces are easy to navigate. Light gray text on white looks elegant in a mockup, but it's unreadable for many people with low vision.

Developers determine whether code works with assistive technology. They decide whether a custom dropdown works with a keyboard. If it doesn't, someone who can't use a mouse is denied access to the webpage.

Marketers and content creators shape whether messages are clear, readable, and understandable. They write the ALT text, captions, and headlines. A video without captions excludes people who are deaf or hard of hearing, as well as the metro commuter watching with the sound off.

Human Resources teams influence job applications, employee communications, and training materials. They shape the first impression. If an online application process does not work with screen readers, you've denied access based on a disability.

Leadership determines whether accessibility gets the resources, accountability, and attention it deserves. When accessibility is a budget line and not a company value, it's the first thing to get cut.

Two powerful roles rarely get mentioned in the accessibility conversation. Those roles are procurement and internal audit.

Procurement decides what software, platforms, and vendors the whole company uses. When you buy an inaccessible student system, you deny students with disabilities access to the information and services provided by that system. And your developers can’t fix what they don’t own.

The solution is simple. Require an Accessibility Conformance Report (ACR) in every RFP, and treat a vague answer as a red flag.

Treating procurement as the first accessibility checkpoint will reduce risk, improve digital experiences, and guarantee accessibility is built into technology investments from the very beginning.

Internal audit can ask whether accessibility is built into organizational processes**.** Is there a documented accommodation procedure? Are vendor accessibility claims verified or taken on faith? Audit already checks for controls in security, privacy, and finance, so why not accessibility?

Adding accessibility to the internal audit process makes it something leadership has to track. It also surfaces legal and reputational risk before a complaint does.

Start Small

Building accessibility into organizational culture doesn’t require changing your entire organization overnight. Start small, build accessibility into the work you’re already doing, learn from what you do, and use each step to build the knowledge, confidence, and momentum to take the next one.

Start with these:

Add one accessibility requirement to your project requirement document.
Add one accessibility question in your design reviews, code reviews, and content checklists.
Add an accessibility requirement to your next RFP.
Ask internal audit to include the accommodation process in its next review.
And when you’re ready, embed an accessibility expert directly into each team while the work is happening.

Closing the Gap

Every role has an impact. Every decision can remove a barrier or create one. When everyone understands that impact, it becomes part of how work gets done.

Closing the accessibility gap means building practical accessibility knowledge into the work people already do. Provide teams the guidance and tools they need and make accessibility part of onboarding, professional development, and established workflows. In other words, make accessibility a shared responsibility.

Culture doesn’t shift because of a single accessibility initiative. It shifts when accessibility becomes part of how an organization thinks, makes decisions, and works, one intentional step at a time. Only then can organizations build more inclusive digital experiences from the start.

This NDEAM, let’s think beyond compliance. Let’s build workplaces where accessibility awareness and knowledge are part of how we all work, not just something a few people know.

Resources

U.S. Department of Labor, National Disability Employment Awareness Month

Riding the Magic Escalator of Acquired Knowledge

DubBot — Tue, 13 Oct 2026 00:00:00 +0000

How Acquiring Accessibility Expertise Changes What You See

Years ago, while working in higher education, I came across a concept called the Magic Escalator of Acquired Knowledge. I don’t remember exactly where or when I found it, but I do remember thinking something like, That’s it. That’s how I’m going to approach this. I’m getting on that escalator and taking it one step at a time.

I printed the image and taped it to the giant whiteboard in my office, where I was mapping out a digital accessibility program. I kept that image as a way to think about my own accessibility journey - where my knowledge was at any given time, what I still needed to learn, and, most importantly, where I wanted to go next.

What Is the Magic Escalator of Acquired Knowledge?

The concept, developed by Jared Spool, describes how our existing knowledge shapes what we can understand and accomplish. As our knowledge grows, we start to see patterns, connections, and problems that weren't visible to us before.

But that knowledge doesn't come to us all at once. We acquire it through experience, training, practice, observation, and sharing what we've learned with others.

That idea maps surprisingly well to learning digital accessibility.

When you're new to accessibility, you start with the rules:

Learn WCAG.
Check color contrast.
Add ALT text.
Make your website keyboard-accessible.

Those things matter. They're foundational. But eventually, something changes.

You start seeing accessibility differently.

You notice that a form can technically pass an automated check and still be confusing. You recognize that a link can technically work while providing almost no useful context. You realize that an error message can exist without actually helping someone understand or fix the problem.

That's the escalator at work.

As your knowledge grows, you're not just learning more accessibility rules. You're seeing more of the experience.

From Checking Requirements to Understanding People

A lot has been written about the importance of including automated testing in the overall accessibility auditing and monitoring process. Automated tools can quickly identify many common issues and help practitioners find problems at scale.

But tools don't understand everything about the user’s experience.

They don't know whether the instructions make sense. They can't fully evaluate intent or context. And they can't tell you what it's like for a person using a screen reader to navigate a complicated application process.

That's where human evaluation and acquired knowledge come in.

The more you understand accessibility, the more you begin to ask questions that go beyond Does this meet the requirement?

You start asking:

Can someone find what they need?
Can they understand what they're supposed to do?
Can they complete the task?
Does the experience make sense?
What happens when the content changes?
How would someone using assistive technology experience this?

Your questions become more nuanced as you acquire a deeper, broader view of the user experience.

The Escalator Never Stops

Accessibility knowledge isn't something you suddenly acquire, and then you’re done. You acquire it through training, practice, observation, knowledge sharing, experience, and a better understanding of how people use technology.

The Magic Escalator of Acquired Knowledge reminds us that accessibility expertise isn't gained through memorizing guidelines alone. Practitioners need opportunities to develop and share skills, context, experience, and lessons learned.

Each new encounter offers a new perspective on how people make sense of their digital world. What begins as learning rules and guidelines eventually becomes an understanding of people and their needs, behaviors, and how they navigate digital experiences.

The more steps we take, the better equipped we are to create experiences people can use successfully, regardless of ability, circumstance, or technology.

Resources

Landmarks: Your Webpage’s Table of Contents

DubBot — Thu, 08 Oct 2026 00:00:00 +0000

Recently, the DubBot app flagged several landmark issues across a few of my blog posts. And so, naturally, I began to investigate.

As some of you may have already surmised, the culprit turned out to be the template. That was a bit confusing, considering the template had been in use for a couple of years without any apparent issues. 🤔

Sometimes, accessibility has a funny way of reminding you that it’s been working fine isn’t quite the same thing as it’s working correctly.

Regardless, the necessary updates were made, the landmark issues were resolved, and all was well again.

As I dug deeper into landmarks and how they were being handled in the template, I realized it’s a topic I haven’t seen covered very often in articles or blog posts. They’re an important part of a well-structured, accessible webpage, but they don’t always get the attention they deserve.

So, one template update later, I had a new topic for the DubBot blog collection: landmarks.

What Are Landmarks?

A landmark is a clearly defined section of a webpage with a specific purpose, such as navigation or main content. Landmarks help people, especially those using screen readers or keyboard-only navigation, quickly understand the page structure and tab directly to the section they need.

Think of landmarks as a webpage’s table of contents. Instead of reading or listening to everything from top to bottom, screen reader and keyboard navigation users can jump directly to key sections like the main content, navigation, or search bar.

Landmarks are an ARIA concept, but semantic HTML gives you elements that map directly to ARIA landmark roles and create those landmarks automatically, so you don't have to use ARIA.

And with the addition of

(added to the HTML spec in 2023), all eight ARIA landmark roles now have corresponding native HTML elements.

Just another good reason to use semantic HTML whenever possible.

ARIA landmark role	Native HTML element
banner	<header>
complementary	<aside>
contentinfo	<footer>
form	<form>
main	<main>
navigation	<nav>
region	<section>
search	<search>

You will find examples for each native HTML element by reading or listening to Landmark Patterns, Examples.

Two Important Caveats

and
depend on where they’re used. A
can create a *banner landmark* when it’s used at the top level of a page. But when you place a
inside something like
,
, or
, it doesn’t automatically become a banner.
The same idea applies to
. It creates a contentinfo landmark when it’s a child of the element and represents information about the overall page.
A
only becomes a region when it has an accessible name, such as one provided by a heading. Simply adding a
doesn’t create a region landmark.

When to Use Semantic HTML vs. ARIA Landmarks

Use semantic HTML whenever possible. Elements like

, and

From Accessibility Testing to Karaoke: DubBot Heads to DigiCol 2026

DubBot — Tue, 06 Oct 2026 00:00:00 +0000

DubBot is excited to once again join the DigiCol community as a Platinum Sponsor and Accessibility Partner for the 2026 Digital Collegium Annual Conference in Pittsburgh, PA.

Join us in person or online for DigiCol 2026, happening October 18 - 21. This event brings together content creators, strategists, designers, and developers of higher ed to connect, share, and learn from one another. This is the premier gathering for higher education professionals passionate about digital innovation.

Whether it’s content strategy, UX, accessibility, AI, or the day-to-day realities of managing digital systems in higher ed, DigiCol has always been about community. A space where people come together to share ideas, collaborate, and learn.

Be sure to attend Penny Kronz’s session, Ensuring Website Accessibility through Automated and Manual Testing, where she’ll share practical insights into how automated and manual testing work together to identify and address accessibility issues.

And when the workday is done, we’ll be trading accessibility checks for microphones! And we’re pretty excited about it!

DubBot is teaming up with our friends at Evolving Web to sponsor the Karaokeplane on Tuesday evening at Tequila Cowboy.

Nothing brings the higher ed digital community together like swapping website governance stories for microphones, turning up the music, and seeing who’s ready to take the stage.

We’ll see yinz in Pittsburgh!

#DigiCol26

🎤

Keeping Your Website Accessible: The Case for Regression Testing

DubBot — Thu, 01 Oct 2026 00:00:00 +0000

You spend a lot of time remediating accessibility issues. Every image has ALT text, focus order makes sense, and forms work with screen readers. But a new feature, design update, content change, or code fix can undo that hard work and introduce an accessibility issue without anyone noticing. That’s why you should build regression testing into your accessibility testing process.

That’s why regression testing belongs in your regular accessibility workflow. Test, make changes, test again. It’s how you make sure the accessibility fixes you worked so hard to make stay put.

What Is Regression Testing?

Regression testing means re-running your existing test cases after any changes to your website or other digital assets to make sure existing accessibility hasn’t broken. In other words, it checks whether the change introduced a new accessibility issue or made an existing one worse.

Regression testing differs from retesting. Retesting checks whether a specific issue was fixed, while regression testing tests whether that fix broke something else in the system.

For example, a developer might update a form component and accidentally remove a label association. A redesign might introduce a color combination that no longer meets contrast requirements. A change to a modal could affect keyboard navigation or focus management.

Accessibility is functionality, and it breaks the same way everything else does. Regression testing will help identify those breaks before they make it into production.

How to Maintain Website Accessibility After Updates

Because regression testing is repetitive, it’s a natural fit for automation. Tools like DubBot can continuously scan your site for accessibility issues, ensuring updates, deployments, and design changes don’t reintroduce barriers you've already resolved. The result is a more sustainable accessibility testing process that supports long-term compliance, protects hard-won progress, and keeps accessibility integrated into your day-to-day workflow rather than treated as an occasional audit exercise.

The most practical approach to regression testing is to:

Establish a baseline. Test your current website or key components and document existing accessibility issues.
Make your changes. Roll out that new feature, redesign, bug fix, or content update.
Run the same accessibility checks again. This is where automated testing really is a rockstar. It can quickly flag new WCAG issues.
Compare the results. Look specifically for new or worsened issues and don’t treat existing issues as new issues.
Manually verify changes. Include manual testing, along with automated tools for regression testing, to ensure keyboard navigation, focus behavior, how screen readers announce content, and complex interactions remain accessible and usable.

Prioritize features that will stop a user in their tracks if they were broken. Features like user login, navigation, completing a purchase, or registering an account.

The Benefits of Regular Regression Testing

Regular accessibility regression testing makes accessibility part of your continuous website monitoring, rather than something that happens periodically.

Run automated checks as part of your development or content workflow to shift left in accessibility and flag issues when they are easier and cheaper to fix.

By pairing automated testing with manual testing, you create a sustainable, repeatable approach to accessibility that scales with your site and gives you a better chance of protecting the accessibility of the entire user experience.

An accessibility audit captures your website's current state at a given point in time. Regression testing keeps that current state accurate and up to date as your site changes and evolves. By building accessibility checks into every feature release, code update, and redesign, you can catch new issues before they undo your progress and help ensure everyone can keep using your website.

Resources

Graphical Objects, UI Components, and Contrast

DubBot — Tue, 29 Sep 2026 00:00:00 +0000

While working to correct some minor policy issues reported in the DubBot app, two pages were flagged for Image alt text is less than 12 characters.

When I opened the Detailed Page View, I saw that the images were small, like icons, and gray in color. Since they were part of instructional text, I double-checked the contrast using WebAIM’s contrast checker.

Here’s what the results told me. The contrast failed WCAG AA & AAA for Normal Text, and WCAG AAA for Large Text. But passed the third contrast check, which applies to Graphical Objects and User Interface Components.

That was like an Ah-ha moment for me. I think we tend to pay attention to color contrast for text and focus indicators, and forget that other visual elements matter too. UI components like buttons and graphical objects like meaningful icons also need sufficient contrast to provide clear visual cues.

So I decided to dig into what that third result for WebAIM actually means, and why it has its own line in the contrast checker.

WCAG 1.4.11 Non-text Contrast

Success Criterion 1.4.11 Non-text Contrast is a Level AA requirement. It says that certain visual information must have a contrast ratio of at least 3:1 against adjacent colors. That applies to two categories.

The first is User Interface Components - the visual cues people need to recognize a control and identify what state it's in. For example, the filled portion of a progress bar, or a checked checkbox.

The second is Graphical Objects. These are the parts of an image or graphic someone needs in order to understand the content. Meaningful icons, along with lines and bars in a chart or arrows in a diagram, are included in this category.

Think of these two categories like this. User Interface Components help people interact with a page. They tell the user:

This is a button.
This checkbox is checked.
This toggle is on.

Graphical Objects convey content through graphics. They help people understand the page information.

For example, a weather dashboard. The button to switch between hourly and daily forecasts is a user interface component. Its border, background, or other visual characteristics need sufficient contrast so users can identify and operate it.

The temperature graph, where the lines communicate temperature changes, is a graphical object. The lines or other visual elements needed to understand the data need sufficient contrast.

For comparison, regular text under SC 1.4.3, Contrast (Minimum) (Level AA) needs 4.5:1, and large text needs 3:1. That's why my gray icons failed the Normal Text check but still pass the Graphical Objects check. Their contrast landed somewhere between 3:1 and 4.5:1, which is enough for an icon but not enough for body text.

Please note this important caveat from WebAIM related to 1.4.11 Non-text Contrast:

There is one notable difference in how contrast requirements are applied. Contrast requirements in WCAG 2.0 are between text and background, but 1.4.11 requires contrast of at least 3:1 against adjacent color(s), which means you may need to measure contrast in more than one place. A non-text element may have different contrast on one side than the other (like a wedge in a pie chart), or it may contain different-colored components that need 3:1 contrast with each other. ~ Contrast and Color Accessibility

Exceptions to SC 1.4.11 Non-text Contrast

A few exceptions are worth knowing so you don't chase issues that aren't really issues.

Inactive or disabled components are exempt. A grayed-out Submit button that isn’t currently usable doesn’t have to meet 3:1 contrast, though it’s still good practice to make it clear that the button exists and why it’s disabled.

Components whose appearance is set entirely by the browser, and not changed by the author, are also exempt. If you've left a default checkbox alone, the browser's styling is the browser's responsibility.

Graphics where a specific presentation is essential, meaning if those graphics were removed, it would fundamentally change the information or functionality of the content, do not have to meet the contrast ratio. For example, a logo or brand mark, or a map showing geographic boundaries.

And decorative images, the ones that don't convey any information, are outside the scope entirely.

Why Does This Matter?

Low-contrast icons and controls are hard to see for people with low vision, people with color vision deficiencies, and really, anyone using a phone outside on a sunny day or looking at an older, dimmer monitor. If someone can't see the outline of a form field, they may not realize the field has been selected, and that is where they need to enter the information. If they can't see the icon in an instruction like Select the gear icon to open settings, the instruction stops making sense.

That second example is exactly the situation I ran into. The icons were part of the instructions. If a user couldn't see them clearly, they couldn't follow the steps.

Back to Those Flagged Images

So what about the original ALT text flag? Checking contrast was a detour, but a useful one, because it confirmed the icons were meaningful and visible enough to meet WCAG 1.4.11. That meant they also needed ALT text that did their job in context.

Short ALT text isn't automatically wrong. An icon with ALT text like Settings can be perfectly appropriate. DubBot's Custom Policy check is a prompt to take a second look, not a verdict. In my case, reviewing the images in context helped me confirm whether the ALT text described what each icon represented within the instructions, and adjust where it didn't.

Remember: color contrast isn't just a text issue. Any time an icon, border, chart element, or control state carries meaning, it needs a contrast ratio of at least 3:1 against the surrounding colors. So next time you run a contrast check, don't stop at text alone.

Resources

Web Accessibility Evaluation Guide
Understanding SC 1.4.11 Non-text Contrast (Level AA)
Contrast and Color Accessibility - Understanding WCAG 2 Contrast and Color Requirements

Organize DubBot Your Way with Labels

DubBot — Thu, 24 Sep 2026 00:00:00 +0000

Every organization manages its websites, page sets, and task responsibilities in different ways. You could manage sites by department, audience, campus, or business unit. You may want to distinguish tasks by status, priority, or workflow.

Now, DubBot lets you apply that same approach to your organization’s structure and workflows right in the app with Labels.

Labels are customizable tags that help you organize and filter Sites, Page Sets, and Tasks in ways that make sense for your organization. Account-level Administrator and Manager roles can create labels, giving your organization the flexibility to build a system around existing workflows rather than forcing workflows into a predefined structure.

Make It Easier to Find What You Need

Labels help you quickly find and focus on what you need.

As your digital presence grows, finding the right information quickly becomes as important as having it in the first place. Labels give you a simple way to narrow your scope and focus on what matters.

For example, you can create Site or Page Set labels based on department, audience, or organizational area. Once you apply those labels, you can filter listings and dashboards to locate a specific group of sites or page sets.

Labels can also add more structure to Tasks. Use them to track workflow stages such as To Do, In Progress, and Resolved. You can assign one or more labels to Tasks and filter by those labels when you need to zero in on a particular set of work.

Note: All Labels are visible to all account holders. Creating and managing labels requires an Administrator or Manager role. Labels are also available on applicable CSV downloads.

Build a System That Fits Your Workflow

Creating a label is straightforward. Choose whether the label applies to Sites, Page Sets, or Tasks, then give it a name, description, and background color. Because labels are specific to each object type, you can create a labeling system that reflects your organization's structure and workflow.

And that's the idea. Labels let you bring that structure into DubBot, making it easier to find, filter, and manage the work that matters to you.

Resources

Your Personalized Message Isn’t Very Personal If I Can’t Use It

DubBot — Tue, 22 Sep 2026 00:00:00 +0000

Think about the last personalized email you received. That message that greets you by name, recommends exactly what you’ve been looking for, and arrives at precisely the right moment.

Now imagine the text is light gray. The CTA button doesn’t work with your keyboard, and the hero image contains all the important information and has no ALT text.

Is that really a personalized experience?

We’ve become so obsessed with personalization. We track clicks, purchases, information requests, browsing behavior, location, preferences, and past interactions. We use all that data to deliver the right message to the right person at the right time.

But we don't always stop and think about how people read, navigate, and interact with our carefully crafted messages.

Maybe we’ve been going about personalization all wrong. 🤔

In his article, The Business Case for Accessible Communications in a Personalized World (LinkedIn), Michael Kaminski tells us that accessibility can be integral to personalization. Whether the communication is transactional, informational, or promotional, it can, and should, be both relevant and inclusive.

Using my name is personalization.

Knowing what products I’m interested in is personalization.

But can I actually understand, navigate, and interact with your communication?

That's where accessibility and personalization intersect.

Personalization is about delivering a message that is relevant to an individual. Accessibility is about making sure that individual can actually perceive, understand, and use it. Those should not be separate considerations.

Personalization is More Than Just Knowing My Name

We often think of personalization as putting someone’s name in an email or serving up content based on what they’ve clicked on in the past. But personalization is about more than just knowing who someone is. It’s understanding how they experience information.

People read, navigate, listen, search, and interact with content in all kinds of different ways. Truly effective personalization recognizes those differences and is accessible, inclusive, and designed for how people actually interact with information.

And the good news is making your communications accessible isn't all that complicated. Truly effective personalization looks like this:

Sending a personalized email?

Use actual text instead of embedding important information in an image.
Give informative images meaningful alternative text.
Use sufficient color contrast.
Make links and buttons descriptive.
Structure content with headings that make sense.
Don't rely on color alone to communicate information.

Sending personalized video? Include accurate captions and transcripts. If you communicate important information visually but not through speech, provide an accessible alternative.

Creating personalized documents? Don't assume that exporting a Word document to PDF magically makes it accessible. Make sure your PDFs and all other digital documents have proper headings, reading order, tagged content, accessible tables, and useful metadata.

Building personalized forms? Give every form field a meaningful label, make instructions and error messages clear, and ensure the form can be completed with a keyboard and assistive technology.

And perhaps most importantly, don't assume everyone wants or needs to experience your communication in exactly the same way. Offering choices for communication format, language, or channel can itself be a form of personalization.

None of these best practices undermine personalization. In fact, they raise the bar. The goal isn’t to create a more customized experience for some people at the expense of others. When you design for how people actually experience information, you’re not taking personalization away; you’re making it more effective.

Knowing who I am doesn't matter much if you don’t consider how I experience your message.

Shift Left in Your Personalized Communications

Personalization asks: What’s the right message, offer, or content for this person, and when should they receive it?

But another question belongs in that decision: Can this person access, understand, and interact with the message we’ve carefully crafted for them?

Because a personal experience isn’t truly personal if someone can’t use it.

You can have the world's most sophisticated personalization engine and still deliver a terrible user experience.

Accessibility isn’t something to inject after you’ve created your communication. It’s part of creating a meaningful, inclusive communication from the start.

When you're deciding what message someone should receive, also consider how they will access it.

Accessibility as a Competitive Differentiator

Making communications more inclusive can significantly expand an organization's reach. It can also strengthen customer loyalty by demonstrating a commitment to inclusivity and care, values that increasingly influence consumer choice.

But as expectations evolve, leading organizations are recognizing that inclusive design is more than a legal safeguard. It’s an opportunity to build deeper relationships with customers and deliver better experiences for all.

Once treated as a regulatory obligation or compliance checkbox, accessibility is now emerging as a competitive differentiator. ~ The Business Case for Accessible Communications in a Personalized World, Michael Kaminski

The main takeaway here is this. The goal of personalization shouldn’t simply be to make people feel seen. It should be to make sure they can participate. A message isn’t truly personal if the person it’s meant for can’t access it, understand it, or act on it.

Think of it this way. Personalization gets your message to the right person. But accessibility makes sure it actually includes them.

Resources

Table or List? Choosing the Right Structure for Accessible Content

DubBot — Thu, 17 Sep 2026 00:00:00 +0000

Tables and lists are both very useful ways to organize and present content. But they’re both structured to present different types of content. Choosing the right one isn't just a design decision. It’s also an editorial and accessibility decision. The right choice can make content easier to understand and navigate for everyone, including people who use screen readers, magnification, keyboard navigation, or mobile devices.

Let’s start with a question: Is the content relational data, or is it simply a group of related items?

Answer: If rows and columns are needed to make sense of the relationship between data points, use a table. If not, consider using a list.

For example, a class schedule.

A simple list would tell you that Biology meets on Monday, Wednesday, and Friday. But with the row-and-column relationship, you can quickly associate a particular course with a particular day and time.

Course	Monday	Wednesday	Friday
Biology 101	9 a.m.	9 a.m.	9 a.m.
English 201	10:30 a.m.	No class	10:30 a.m.
Chemistry 110	No class	1 p.m.	No class

When Should You Use a List?

Use a list when you're presenting a collection of related items, concepts, or steps.

Lists work particularly well for:

Steps in a process or procedure.
A collection of related items.
Requirements or recommendations.

Lists are generally easy to scan visually, straightforward for screen reader users to navigate, and require less cognitive effort, making information easier to understand quickly.

They are especially helpful on smaller screens because list items reflow naturally to the available space rather than requiring horizontal scrolling.

Note: As Dax Castro points out, long,nested lists can overwhelm screen reader users and folks with cognitive challenges. So keep your lists simple, no more than two levels deep.

Make Your List Accessible

Instead of creating the appearance of a list with manually typed bullet symbols or numbers, use proper semantic HTML with

for unordered lists and
for ordered, sequential step lists.

This supports WCAG 2.2 Success Criterion 1.3.1, Info and Relationships, which requires meaningful structure and relationships to be programmatically determinable.

Use bulleted lists for a list of related items. For example:

Apples
Oranges
Bananas
Grapes
Strawberries

Use a numbered list when order matters, such as steps that must be completed in a specific sequence. For example:

Open the website.
Select Sign In.
Enter your username and password.
Select Submit.
Confirm that you’re signed in.

When Should You Use a Table?

Use a table when people need to understand relationships between two data points. For example, the class schedule above, financial data, statistics, or other content where the meaning of the data in one cell depends on its corresponding row and column headers.

For example, this high tide schedule.

For this type of content, a table is more effective than a list because the information has multiple related attributes of Day, Time, and Tide Level that need to be compared across rows to make sense and be of value.

Day	Time	Tide Level
Monday	8:15 a.m.	3.2 ft
Tuesday	9:02 a.m.	3.5 ft
Wednesday	9:48 a.m.	3.7 ft

Using a table to convey this type of content helps:

make relationships clear, as each day is directly associated with its corresponding time and tide level.
support quick comparisons so the reader can scan down the columns to compare times or tide levels across days.
provide a consistent structure with each row following the same pattern, making the information predictable and easier to understand.

Tables can be particularly useful for people who need to compare multiple pieces of content at once. But they can also be harder to navigate with a screen reader or on a small screen, so they shouldn't be the default choice when a list or even a paragraph would communicate the information just as well.

When in doubt as to whether to use a table or a list, go back to our original question (and the answer) at the beginning of this blog post:

Is the content relational data, or is it simply a group of related items?

Make Your Table Accessible

Use proper semantic table markup, not a visual grid.
Identify row and column headers with .
Associate headers and data cells so meaning is programmatically determined.
Provide a meaningful caption when useful.
Keep the structure simple and avoid merged cells.
Ensure sufficient text and background contrast.

These practices also support WCAG 2.2 Success Criterion 1.3.1, Info and Relationships, by ensuring that relationships between headers and data can be programmatically determined.

Simplicity is an Accessibility Strategy

Accessibility isn’t always about technology. Sometimes, it’s about the content itself and making thoughtful, strategic choices about how that content is structured from the start. The goal is to choose the simplest structure that communicates information clearly and works well for the widest range of people. Knowing when to use a table and when a simple list will do is an editorial and design decision that will make content easier to scan, understand, and navigate.

Good accessibility often starts with simple choices like less complexity, more clarity, and a structure that helps people get to the information they need.

Resources

Understanding Accessibility Debt: How It Happens and What to Do About It

DubBot — Tue, 15 Sep 2026 00:00:00 +0000

Folks rarely set out to build something inaccessible. But tight deadlines, understaffing, and budget constraints can push shift-left accessibility activities to the sidelines, creating gaps and missteps that are harder to address later. Issues like a button without a label, an image missing ALT text, or an unlabeled form field. On their own, they sound minor, but left unresolved, they build up into a backlog. That backlog is called accessibility debt.

And that backlog can make it difficult, or even impossible, for many people to use your website, app, or software. Not to mention, the longer it goes ignored, the harder and more costly it becomes to fix.

How Does Accessibility Debt Happen?

Accessibility debt can build up in small ways:

Moving files from concept to development without accounting for accessibility.
Reusing existing patterns and components to save time, without anyone evaluating their accessibility, can replicate the same accessibility issues from project to project.
Tight timelines can push testing to just mouse and keyboard, leaving other ways of interacting - screen readers, for example - out of the process.
A lack of accessibility training and expertise can make issues harder to spot.

Over time, these shortcuts add up, and what started as a few overlooked issues can become a much larger accessibility problem.

Real-World Consequences

Accessibility debt isn't simply a backlog of technical issues. It's the accumulating cost of leaving them unresolved. The longer they remain, the more they can affect your users, designers and developers, budgets, timelines, and organizational risk. Accessibility debt has real operational consequences, such as:

Loss of user trust.
When prospective customers, students, employees, donors, or community members repeatedly encounter an inaccessible digital experience, they may stop relying on your website or choose another organization’s website that is easier to use, possibly causing you to lose revenue as well.
Backlog becomes harder to prioritize.
As the number of unresolved issues grows, it becomes harder to distinguish between quick wins, systemic problems, and issues that have the greatest impact on users.
Support requests increase.
People who can't complete tasks independently may need to contact support, request alternative formats, or ask someone else for help.
Compliance and legal risk can increase.
Constant accessibility issues can contribute to user complaints, investigations, or legal action, depending on the organization and applicable requirements.
Time spent fixing the same issues repeatedly.
Without addressing the underlying process or pattern, designers, developers, and content creators may keep encountering and repairing the same or similar accessibility issues.
Remediation competes with new priorities.
Accessibility fixes have to share limited time and resources with new features, redesigns, content initiatives, and other organizational priorities.
Development and project schedules get disrupted.
Last-minute accessibility fixes can force designers, developers, and content creators to revisit completed work, possibly delaying launches or releases.
Accessibility work becomes harder to defend.
If accessibility wasn't established as part of the project requirements, standards, or the Definition of Done, you may find yourself having to make a new case for why an issue needs to be fixed after the work was already considered completed.

The biggest consequence of accessibility debt is the people it leaves behind. People who can’t access information, complete a task, apply for something, make a purchase, register for an event, or participate because a digital barrier gets in their way. And often, the people most affected can’t even get far enough into the experience to report the problem. So, how do you determine your accessibility and start paying down that debt?

How To Uncover and Start Eliminating Accessibility Debt

Accessibility debt won’t resolve itself. The first step is understanding where those barriers exist, then putting a plan in place to address them.

The first step is understanding the scope of the problem, and that starts with thorough testing. Automated tools like DubBot can quickly flag common accessibility issues, and manual testing like using keyboard navigation, screen readers, and focus-order checks helps uncover barriers automation can miss.

Next, track the problem like any other metric: open violations by severity, unaudited components, and meeting accessibility standards on every new feature, so you don't create new issues while fixing old ones. Prioritizing the most visible or disruptive barriers helps focus limited time and resources where they make the biggest difference, while also helping make the case for continued accessibility work. Read or listen to 7 Core Accessibility Skills from the University of Minnesota for information on high-impact, quick-win accessibility fixes.

Give the whole team, not just one specialist, working knowledge of accessibility basics and remediation best practices. Make training a regular, required activity for designers, developers, and content creators across your organization.

Build accessibility into design and code reviews, not a separate audit at the end. This is what shifting left in accessibility looks like. Make accessibility part of the project process from the very beginning. From project requirements to acceptance testing.

Review your content strategy and make sure you have included accessibility. True strategic planning integrates accessibility alongside audience and persona research, positioning accessibility and inclusion as core business insights rather than afterthoughts.

Most importantly, include people with disabilities in the testing process. They’ll find what a checklist can’t. Automated and manual testing can tell you whether specific accessibility requirements are met. Still, people with disabilities can identify real-world usability issues and tell you whether a website actually works for them, where the experience breaks down, and why. Involving people with disabilities brings lived experience into the development process, with their feedback shaping design, content, functionality, and testing practices while helping identify and address accessibility issues before they become harder and more expensive to fix.

Going From Accessibility Debt to Accessibility System

Think of accessibility as a system, not a one-time fix for accumulated debt. Fixing today’s issues is important, but it’s only part of the work. Lasting accessibility comes from building it into how your organization operates using clear strategy, shared rules, defined ownership, and ongoing oversight. Strategy sets the direction. Policy sets the expectations. Continuous monitoring provides the ongoing feedback needed to identify new issues as your website changes. Together, they turn accessibility from a backlog to manage into an ongoing practice.

Resources

Why don't we use black text anymore? That's an Excellent Question, Diana!

DubBot — Thu, 10 Sep 2026 00:00:00 +0000

Sometimes it's a good thing I’m not in an office during work hours. Here’s a perfect example of why. When I saw the headline of one of my regular email subscriptions, I screamed out loud, Damn skippy! I’ve been asking that question for years!

What was the headline that elicited such an enthusiastic response? The headline read: Why don't we use black text anymore? It was pinned by Diana Khalipina (LinkedIn) in the Sept.6 issue of her daily publication titled A11y explained with Diana (Substack)

After reading her post, I was even more convinced. Gray text has its place, but it's time to bring black text back.

As web design moved toward minimalist layouts in the 2010s, designers increasingly used shades of gray instead of black for body copy, labels, metadata, and supporting content. The idea was simple. Black text looked too heavy, while gray created a softer, cleaner visual hierarchy and made body copy feel less visually dominant.

The problem is that subtle for some can mean harder to read for others.

The concern isn't that gray is inherently inaccessible. It's how much contrast it has against its background. Gray text on a white background can look elegant on a large monitor in a controlled environment. Still, it can become surprisingly difficult to read for someone with low vision or reduced contrast sensitivity.

And the difficulties are not limited to people who identify as having a visual disability.

Try reading light-gray text on your phone outdoors. Add sunlight, screen glare, a smaller display, or a slightly older pair of eyes. Suddenly, that carefully chosen subtle gray isn't so elegant. It’s simply difficult to see.

Black or near-black text generally provides the strongest contrast on white backgrounds, making body copy easier to read, especially for people with low vision or in bright, glare-heavy conditions. Gray text can work for secondary content, but lighter shades may be harder to perceive and can fall below WCAG contrast requirements.

WCAG 2.2 Level AA requires a 4.5:1 contrast ratio for normal-sized text and 3:1 for large text.
And according to WebAIM,

You cannot round a contrast ratio up to 4.5:1. For example, #777777, a commonly-used shade of gray with a 4.47:1 contrast ratio, does not meet this requirement. ~ Contrast and Color Accessibility

This is #777777 gray text on a white background.

When in doubt, choose darker text to maximize readability and move closer to meeting accessibility requirements.

Black or near-black text doesn't have to mean abandoning visual hierarchy. Use font size, weight, spacing, layout, and white space to make visual design more accessible to people with disabilities. Gray still has its place. But if we're choosing between subtle and readable, perhaps readable should win more often. Good design shouldn't ask users to work harder to read the content.

It isn't about making every website look like a newspaper. It's about giving the words enough visual weight to hold up in real-world conditions. A very dark gray can provide plenty of contrast while feeling slightly softer than pure black. The key is to check the contrast and test it under different lighting conditions rather than simply eyeballing whether a color is accessible.

Accessibility isn't just about whether something technically passes a test. It's about whether people can comfortably use it in the real world.

If black text gives your readers a better experience, why wouldn't you use it?

Resources

A human author creates the DubBlog posts. The AI tools Gemini and ChatGPT are sometimes used to brainstorm subject ideas, generate blog post outlines, and rephrase specific sections of content. Our marketing team carefully reviews all final drafts for accuracy and authenticity. The opinions and perspectives expressed remain the sole responsibility of the human author.

How Much ALT Text is Too Much ALT Text?

DubBot — Tue, 08 Sep 2026 00:00:00 +0000

While scrolling through LinkedIn the other day, I came across a post from a former intern from my higher-education days. He was sharing a website redesign project he had worked on, and I was excited to see what he’d created. Naturally, I checked out the website and, of course, ran the WAVE extension to see if he remembered what I’d taught him about accessibility.😉

To my delight, he had incorporated accessibility best practices throughout the new site. (Caveat: As much as he could, given the web design tool he was working with.)

But something caught my eye. Not anything he had neglected, but an error description. WAVE had flagged several images, giving this reason: An image has very long alternative text.

I quickly inspected one of the images and found the ALT text: Orchestra performers playing string and wind instruments during a concert, dressed formally in tuxedos and black dresses.

Turns out that's a surprisingly common flag and a useful one, because long ALT text isn't really about length. It's about intent. And that flag points to something screen reader users have to deal with directly.

How Long is Too Long?

There is no official character limit for ALT text, at least not one I can find. Even WCAG doesn’t set a hard number.

Still, it's worth taking seriously, because long ALT text usually signals one of two things: either the ALT text is repeating content already visible on the webpage, or it's trying to do a job the ALT attribute was never meant to do.

Most guidance converges on a similar range: roughly one sentence, often cited as 100 - 150 characters.

WebAIM's own guide to alternative text is clear: ALT text should be equivalent and succinct, and it shouldn't duplicate what's already presented in nearby text or captions.

The W3C's Web Accessibility Initiative says much the same: ALT text should be the most concise description possible, and once you need more than a short phrase or sentence, a long-description technique is the better tool than trying to include everything in the ALT text.

Why Does Too Much ALT Text Matter?

Length matters because of how assistive technology delivers that text. Remember, ALT text has no internal structure, no formatting, no headings, no way to jump by sentence or word the way a screen reader moves through webpage content. Some screen readers cope with very long ALT text by breaking it into chunks and announcing each one separately, so a single image can sound like several unrelated items.

In addition, symbols and line breaks can be skipped or garbled, and an embedded URL is often read aloud letter by letter instead of treated as a link.

A sighted visitor can scan a busy image pretty quickly. A screen reader user has to hear the whole thing, in order, every time. There is no equivalent shortcut.

That's the real cost of long ALT text, not a failed check. Again, it’s about intent. It shapes the listening experience for the very person ALT text is meant to serve.

I don’t see these flagged images as a gotcha moment for my former intern. If anything, they were the perfect full-circle teaching moment. Because even a website built with accessibility in mind from day one can have a few gray areas. Showing us, once again, the critical roles of context awareness and human oversight in accessibility testing.

Resources

Dark Mode vs. Light Mode: Preference, Trend, or an Accessibility Question?

DubBot — Thu, 03 Sep 2026 00:00:00 +0000

Dark mode is no longer a niche developer preference. With the 2019-2020 releases of iOS 13, Android 10, and Windows / macOS system-level toggles into the mainstream, dark mode has since become a widely offered option.

Last week, the Support Team received an unusual support issue related to dark mode. That conversation later led to a discussion with the whole team comparing dark vs. light mode preferences and why.

As the conversation unfolded on Slack, it was clear that, based on who responded, most DubBot team members are fans of dark mode and use it regularly.

Their reasons were mostly physical, such as tired eyes, light sensitivity, and screen fatigue by the end of the day. Some teammates run dark mode permanently and layer on extra tools like blue-light glasses, auto-dimming lenses, and even e-ink readers. Others fine-tune the iOS Reduce White Point setting and make it a shortcut. A few, including me, actually prefer bright screens and find dark interfaces harder to read.

That mix is probably a fair representation of users in general and a pretty good reminder that accessibility isn't always about finding one setting that's best for everyone.

A design that feels comfortable to one person can be difficult or unpleasant for another.

User Preference Matters

Dark Mode Isn't Automatically More Accessible

It's easy to think of dark mode as strictly an accessibility feature. And for some users, it absolutely can improve the experience.

But dark mode itself doesn't guarantee an accessible interface. Accessibility fundamentals must be baked in. Sufficient contrast is essential throughout the interface, not just for text and backgrounds. Keyboard users need visible focus indicators regardless of theme, and non-text elements like buttons, form controls, and graphics need adequate contrast as well. Interactive states like hover, focus, active, selected, and disabled should stay distinguishable, and components should remain equally identifiable and usable across theme changes. Images and graphics also deserve attention, since one that works well on a light background won't necessarily work on a dark one.

And then there’s this: a page can pass accessibility checks in one mode and fail them in another. This was actually the issue that sparked our conversation.

Light Mode and Dark Mode Can Create Different Accessibility Issues

Imagine a website where dark mode passes automated contrast testing, but light mode uncovers several contrast failures.

A text color that has enough contrast in dark mode may not have enough contrast in light mode. A border color that works with one background may disappear against another. A focus indicator that is highly visible in dark mode may become nearly invisible in light mode.

And then there are user preferences, variables like ones mentioned in our conversation. Folks mentioned using things like Reduce White Point, blue-light-filtering glasses, automatic dark mode, and even specialized displays designed to reduce screen glare and brightness.

These are not necessarily accessibility tools, but they are examples of how people customize their digital environments to make screens more comfortable and easier to use.

When designing dark and light modes, the goal should be to make sure both experiences are accessible, usable, and visually effective.

To help make that happen, keep a few things in mind:

Give users a choice when appropriate - If your interface supports both light and dark modes, let users choose the experience that works best for them.
Respect system settings - Many users have already chosen a preferred theme at the operating-system level. Your website should respect that preference rather than making users override it.
Test every supported version - Run accessibility checks on both light and dark themes. Passing one version doesn't guarantee the other will pass.
Look beyond contrast - Color contrast matters, but it’s only one aspect of accessibility. Check focus indicators, component states, icons, borders, images, and other visual cues in both themes.

The Real Preference Isn't Light vs. Dark

The team conversation started out by just learning which mode folks prefer. It ended up an excellent illustration of why accessibility is rarely that simple.

Some people want dark mode all the time. Some want it only at night. Some prefer light mode. Some people adjust their devices in other ways to make screens easier to use.

No single setting solves everyone's needs. And that's okay.

The goal of accessible design isn't to pick the universally correct color scheme. It's to create experiences that respect the fact that different people need different things.

Accessibility rarely comes down to one setting that works for everyone. And sometimes, the best accessibility feature is simply having a choice.

Resources

12 Principles & Best Practices of Dark Mode Design
StatCounter — Android Version Market Share Worldwide (July 2026 snapshot)
StatCounter — iOS Version Market Share Worldwide (July 2026 snapshot)
A Brief History of Dark Mode - From the Matrix-like Displays of the Early ’80s to Today

DubBlog

Meeting the DOJ Title II Compliance: Don’t Forget Your Accessibility Policy

What is a Web Accessibility Policy?

Why Do You Need a Web Accessibility Policy?

What Should You Include in Your Web Accessibility Policy?

What needs to be accessible?

Which accessibility standard are we following?

Who’s Responsible for Creating and Maintaining Website Accessibility?

The Ultimate Accountability

Designers

Developers

Content Creators and Editors

Procurement and Third-Party Vendors

How will accessibility be monitored and maintained?

Why Finalize the Policy Now?

Resources

A First-Timer's Take on Digital Collegium 2026: Pittsburgh, New Perspectives, and Great Connections

A Warm Welcome (and a Little Friendly Competition)

A Little Sunshine in Pittsburgh

Beyond the Sessions: Making Accessibility Approachable

PDFs, PDFs, and More PDFs!

From Screens to Real Life

Until Next Time, Digital Collegium!

Getting More From Custom Labels: Smarter Page Sets in DubBot

Quick Review: A Smarter Way to Organize Sites

Label-based Page Sets: How They Work

Bringing You More Strategic Oversight

Resources

Is Your Website Relying on Color Alone?

Who Does Use of Color Affect?

What Does a Color-Only Accessibility Issue Look Like?

How Do You Fix Color-Only Issues?

One Important Distinction

Make Testing for Use of Color Part of Your Accessibility Strategy

Resources

More Than Documentation: Getting to Know the DubBot Help Center

Are You Just Getting Started?

Are You a DubBot Administrator?

Not Sure What That Accessibility Issue Means?

Need to Find Answers Faster?

And When You Need a Human?

DubBot’s Got You Covered

Why the Right Conference Makes a Difference

Benefit From People Who Get It

Take Home Action Items, Not Just Cool Swag

Go Beyond Networking

Finding the Value

End-to-End Accessibility Testing: Going Beyond the Page

What Is End-to-End Accessibility Testing?

Users Have Goals, Not Test Cases

Build Your Scenarios Around Tasks, not Components

Scenarios You Should Consider

Making The Connection

Resources

Celebrate NDEAM: Build Accessibility Into Everyday Work

Accessibility Awareness at Scale is What Changes an Organization

Start Small

Closing the Gap

Resources

Riding the Magic Escalator of Acquired Knowledge

How Acquiring Accessibility Expertise Changes What You See

What Is the Magic Escalator of Acquired Knowledge?

From Checking Requirements to Understanding People

The Escalator Never Stops

Resources

Landmarks: Your Webpage’s Table of Contents

What Are Landmarks?

Two Important Caveats

When to Use Semantic HTML vs. ARIA Landmarks

From Accessibility Testing to Karaoke: DubBot Heads to DigiCol 2026

Keeping Your Website Accessible: The Case for Regression Testing

What Is Regression Testing?

How to Maintain Website Accessibility After Updates

The Benefits of Regular Regression Testing

Resources

Graphical Objects, UI Components, and Contrast

WCAG 1.4.11 Non-text Contrast

Exceptions to SC 1.4.11 Non-text Contrast

Why Does This Matter?

Back to Those Flagged Images