Last week’s Drupal AI webinar, Choosing the Right AI Tools for Content and Marketing, brought together a global audience and a powerhouse panel. Jamie Abrahams, Alan Botwright, and Matthew Saunders spoke while being moderated by Paul Johnson. Together, we tackled pressing topics facing digital leaders: how to harness AI to deliver real marketing value without getting lost in hype or hamstrung by complexity.

The webinar attracted attendees from more than 20 countries and nearly 80 participants at its peak. This session wasn’t a technical demo. It was an honest conversation about challenges of implementing AI in today’s constrained marketing landscape.

Paul started the conversation by framing the discussion with some statistics. Budgets are under pressure.

Gartner released a report indicating that marketing budgets have dropped to around 7.7% of company revenue, down from 11% in pre-COVID days and this is looking to be the new normal. Combined with that, expectations are rising. Boards want more measurable results, greater efficiency and faster delivery. So everyone needs to do more with less. 59% of CMOs have insufficient budget to execute their strategies and most of them are looking towards AI to have as a possible lever to address this gap or at least try and bridge it. But there are real risks here. Teams are often starting with the technology and then going looking for problems to solve with that technology and that rarely delivers value and often leads to stalled initiatives. How do you help your clients avoid this solution-first mindset and what does a more structured problem-led approach look like in real marketing environments?

– Paul Johnson

Highlights & Key Insights

1. Start with the Why, not the Tool

Too many teams jump into AI with a solution-first mindset. The panel pushed hard against that.

You need to understand the whats and whys before you start tackling the hows.

– Matthew Saunders

We stressed the importance of identifying repetitive, data-heavy, and feedback-loop-dependent processes. Things like content review gates or asset tagging as the most valuable opportunities for automation.

2. AI is not Magic, It’s Smart Math

Jamie framed Large Language Models (LLMs) not as creative geniuses, but as very good pattern recognizers. They’re more “clever librarians” than original thinkers.

LLMs are not doing reasoning in the human sense, they’re more like an extremely good search engine of human knowledge.

– Jamie Abrahams

Expecting them to invent breakthrough creative or strategy will leave you disappointed. But as support for summarising, filtering, and speeding up content workflows? They become an efficiency booster.

3. Human-in-the-Loop is Non-Negotiable

AI isn’t a replacement for people, it’s a partner. Matthew walked through a mini case study where AI was used to aid in brand guideline compliance audit, reduce SLA reporting times by 80%, and streamline asset pipelines. But in every case, humans remained in control.

We never removed people from the loop. The AI was an assistant, not an overlord.

– Matthew Saunders

This framing, AI as a force multiplier, resonated across the panel. Alan added:

You can never spend too much time framing the problem. Once that’s clear, everything else starts to fall into place.

– Alan Botwright

Jamie suggested that human soft-skills are going to be increasingly important and that those with educational backgrounds not grounded in computer science might adapt more quickly.

People with psychology or literature backgrounds often adapt to AI tools faster than engineers. Soft skills are a real superpower here.

– Jamie Abrahams

4. Data Sovereignty Matters

The team then tackled one of the biggest blockers to enterprise adoption: where does your data go?

If you’re using a public LLM, your data is not private. Full stop.

– Matthew Saunders

The options? Either host your own (complex, but sovereign) or work with a trusted provider who can guarantee control over data storage and model access.

5. Cost Isn’t Just About Tokens

Licensing, training, integrations, governance, and internal change management all add up. Matthew suggested teams run a “pre-mortem”:

Ask: a year from now, this AI rollout failed. Why? Map every reason—and you’ll surface the hidden costs before they become real.

– Matthew Saunders

Jamie added that the best outcomes come from constrained agents and narrowly scoped tasks. Not sprawling generalist bots.

If you make your agent or LLM do as little as possible, it’s much more likely to get it right.

– Jamie Abrahams

6. Open Source + Drupal = Strategic Advantage

When asked why Drupal AI matters and what it means to organizations, the panelists had quite a bit to say:

You can build and demo an end-to-end AI prototype in 5 minutes on Drupal. No other open platform gives you that kind of agility.

– Matthew Saunders

This isn’t just a tech shift—it’s a change program. Trust, communication, and alignment across teams are critical to success.

– Alan Botwright

Drupal’s built-in abstraction layers mean you can swap models, switch providers, and adapt as the AI landscape evolves—without rearchitecting everything.

Final Thoughts

This was a real-world conversation grounded in experience: how to launch, govern, scale, and sustain AI in environments with limited budget, complex regulation, and high user expectations.

If you missed the session or want to share it with your team, the full recording is available here:

https://youtu.be/thCrVYlw1Bk

Got questions or want to connect around Drupal AI or implementation strategies? Drop by the Drupal AI Slack channel or check out the Drupal AI LinkedIn page.

Thinking about AI for marketing? Discover how to identify high-impact use cases for AI adoption and avoid common pitfalls in our recorded expert-led AI webinar.

Interested in exploring this topic more ? Join our live accessibility webinar on August 15 at 12 pm EDT with Janell Sims, Manager of Digital Accessibility Services at Harvard University.

When we talk about web accessibility, it's easy to focus on guidelines and checklists. But in practice, not every feature on a website is easy to make accessible. Some elements—like custom search filters, maps, or dropdown menus—require more testing and creativity than others. 
At Evolving Web, we’ve encountered many of these challenges firsthand. In this post, we’re sharing some of the techniques we’ve used when tackling tricky accessibility issues.

To meet WCAG AA guidelines and create genuinely usable experiences for all, we regularly use tools like Axe DevTools, DubBot, SortSite, and Siteimprove. But using accessibility testing during development and QA generally uncovers issues too late in the process. That’s why it’s important to plan for the features that will require extra accessibility work. Designers, strategists, project managers, and QA specialists all play a role in identifying those tricky areas from the start.

Making Megamenus Accessible

Megamenus often include more than just a list of links — they might have headings, images, featured articles, short blurbs, or even interactive elements like buttons or embedded search fields. But adding these elements creates accessibility challenges if the keyboard and screen reader experience isn’t carefully planned.

Issue

When content beyond basic links is added to a megamenu, users navigating via keyboard or screen reader may:

• Not be able to reach all content using the Tab key if focus isn’t properly managed.
• Get stuck in the menu due to keyboard trap loops, especially if tabindex is misused.
• Lose track of where they are because menu sections aren't announced clearly.

Workaround

• To make the entire megamenu accessible — not just the links — we apply a few specific techniques:
• Ensure all focusable elements inside the open menu (links, buttons, form fields) are reachable in a logical tab order.
• Use aria-expanded="true" on the parent menu item when the menu is open, and aria-controls to reference the submenu container.
• Add aria-hidden="false" to the open menu container so that screen readers know when the menu content is available.
• When the menu opens, move focus into the first focusable item inside the panel, and use keyboard listeners (like Escape key and arrow navigation) to allow users to exit or move between items cleanly.
• Ensure visible focus styles are present for extra headings and buttons in the menu dropdowns

Example

The  ROM museum website opens a megamenu under the “Visit” tab. The menu displays three content columns: a list of links like Visitor Information and Accessibility, a visual tile for Museum Maps & Tours with an image, and another for Location & Parking. On the far right, there’s a panel showing admission hours by date. The layout reflects accessibility best practices by grouping content logically, supporting clear tab order, and offering visual structure that could be paired with ARIA roles like aria-expanded and aria-hidden to ensure screen reader compatibility and smooth keyboard navigation.
 

Main Navigation Dropdown Toggling

In many website navigation designs, especially on desktop, the first-level menu items act both as links and as toggles for dropdowns. But combining these two functions in one element can confuse keyboard users and screen readers. To simplify the experience, we often design navigation so that top-level items with submenus act only as toggle buttons, not links.

Issue

When a first-level menu item functions as both a link and a dropdown toggle, it can cause:

• Confusion for keyboard users: Should pressing Enter activate the link, or open the dropdown?
• Inconsistent behavior across screen readers, depending on how the markup is structured.
• Difficulty in managing focus and aria states cleanly, especially when nesting multiple levels.

Workaround

To provide a clearer, more accessible experience, we:

• Convert the parent menu item into a button (or a link with role="button") that only toggles the visibility of the submenu, rather than navigating to a new page.
• Use the first link in the dropdown to link to the top-level page for that section of the website (sometimes it’s a section landing page).
• Use aria-expanded="false" on the toggle button, and update it to true when the dropdown is open.
• Include aria-controls pointing to the submenu container’s id for better screen reader context.
• Ensure the submenu is hidden by default (using aria-hidden="true" and/or display: none), and revealed when toggled open.
• Place focusable items within the dropdown in a logical tab order, and allow for keyboard-only navigation through all items before returning focus to the parent nav.

Example

We implemented this pattern on the Georgia Center website, where the top-level menu items with dropdowns act only as toggles. This makes it easier for keyboard users to explore all submenu items without accidentally navigating away, and it gives screen reader users clear cues about expandable content.

 

Making AJAX Search Filters Screen Reader-Friendly

We love using AJAX to make search filters feel fast and responsive—content updates instantly without reloading the page. But while this improves the visual and performance experience, it creates barriers for screen reader users, who may not realize anything on the page has changed.

Issue

• When results update dynamically (via AJAX), screen readers don’t automatically detect or announce those changes:
• Users may not know their filter selection did anything.
• The results section may change visually, but not be announced to non-visual users.
• Without proper cues, users can feel disoriented or think the filter “didn’t work.”

Workaround

To ensure dynamic updates are communicated to assistive technologies, we:

• Add an aria-live="polite" region around the content area that updates (e.g., search results or counts).
• After filters are applied, add a clear message like “12 results found”.
• Use JavaScript to trigger updates to that region after the AJAX request completes.
• Test the implementation with screen readers to ensure the live region is actually being read.

Example

On the Georgia Gwinnett College website, we provided a screen reader announcement for Drupal views that require page reload. We appended the counter to the “skip to main” link with JavaScript so that it’s being read first after the page is loaded.    

Making Custom Select Menus Accessible

Custom-styled form elements are a favorite of designers, especially when a project calls for a more branded or polished look. But replacing native form controls—like <select> elements—with JavaScript replacements introduces accessibility challenges. While native HTML elements are the most accessible by default, they don’t offer the design flexibility that clients and designers want.

Issue

Custom select menus often:

• Break keyboard navigation (Tab, Arrow keys, Escape) if not fully implemented.
• Lack proper screen reader support, especially for focus announcements, selection changes, and open/close states.
• Trap users inside the field or fail to return focus correctly after selection.

Workaround

To balance accessibility with visual customization, we often use Select2—a JavaScript library that mimics native selects but with better styling and feature support.

Here’s how we make it work:

• Use Select2's built-in accessibility modes, including ARIA support and keyboard navigation patterns.
• Customize behaviour when needed—e.g., ensuring focus returns to the appropriate element after a selection is made, or that assistive tech announces open/closed states correctly.
• Manually test each implementation with screen readers and keyboard to catch edge cases.

Modal Lightboxes Keyboard and Screen Reader-Friendly

When showcasing visual content—like photo galleries, product views, or exhibition highlights—designers often rely on modals or lightboxes to create an immersive experience. While these interactions look great, they can easily become accessibility barriers if not carefully implemented for keyboard and screen reader users.

Issue

Standard lightbox/carousel libraries often:

• Don’t properly trap keyboard focus inside the modal, allowing users to tab into hidden background content.
• Lack appropriate ARIA roles or labels, so screen readers may not recognize the modal context.
• Fail to provide intuitive ways to close the modal with the keyboard.

Workaround

To build accessible modals for image galleries, we use Parvus, a customizable JavaScript lightbox. If a modal is used to display content or a menu, we create a custom modal with JavaScript.

Here’s are some things to make sure you do when implementing a custom modal:

• Add role="dialog" and aria-modal="true" to the modal container so screen readers know it should get the user’s attention.
• Ensure the modal includes a labeled close button (e.g., aria-label="Close modal").
• Hide background content from screen readers using aria-hidden="true" while the modal is active.

Example

On the Royal Ontario Museum site, we use the Parvus library to create the modal lightboxes for exhibits. When users click the info icon on an image, a modal lightbox opens with detailed content and imagery.

Inside the modal:

• Keyboard users can tab through all interactive elements, including text, images, and the close button.
• After the last item, focus loops back to the first item inside the modal.
• Users can press Escape to close the lightbox and resume navigation from where they left off.

Preventing Keyboard Traps in Sliders

Sliders and carousels are commonly used to highlight featured content—especially in hero areas or product showcases. But when using libraries like Swiper.js, this can introduce keyboard accessibility issues, trapping users inside the slider with no way to escape.

Issue

Swiper’s default loop mode duplicates slides to enable infinite scrolling. This has unintended consequences for keyboard users:

• All duplicate slide elements remain in the DOM and are focusable, even if they’re not visible.
• This creates a keyboard trap, where users tab endlessly through duplicated slides and never exit the slider.

Workaround

To fix this, we use a custom JavaScript function to control which elements inside the slider can receive focus:

• We dynamically set tabindex="-1" on all non-visible slides, and remove it only from those currently in view.
• We detect slide changes using Swiper’s event listeners (on: slideChange, etc.) and update focusable elements in real time.
• This ensures that only visible slides are keyboard-reachable, and users can tab forward to content outside the slider.
• We also test the slider with real content (especially when using links or buttons inside slides) to make sure screen readers and keyboard users can interact without confusion.

Example

On one project, we implemented a looping slider using the Swiper library to feature linked articles and stories within each slide. However, with loop mode on, all slide links remained focusable—even off-screen—creating an infinite tab loop. To solve this, we added custom JS to make only visible elements focusable.
This simple adjustment allowed keyboard users to tab through the slider once and move on to the rest of the page.

 

Handling Non-Essential SVG Maps in an Accessible Way

SVG maps can be a visually rich, clickable way to help users explore content—especially for regional directories or filtering tools. But when maps are used as enhancements rather than essential navigation tools, they can create more accessibility challenges than they solve.

Issue

SVG-based maps often:

• Contain many interactive regions that need proper ARIA labeling and keyboard support.
• Are not inherently keyboard-navigable, requiring extensive scripting to manage focus, interactivity, and screen reader compatibility.

Workaround

When maps are non-essential to the user experience we can:

• Hide the map from assistive technologies using aria-hidden="true" or similar techniques.
• Provide a fully accessible alternative—such as a structured list or dropdown.

Example

On the Canada’s Drug Agency website, we used an SVG-based regional map to help users find programs by region. However, making each region fully accessible (labeling, focus control, keyboard behavior) would have required a substantial custom build. Instead, we provide a link to “View Data Table” that shows all the same content in a structured, accessible way.

Making Icons Meaningful for Screen Readers and Editors

Icons are everywhere on modern websites. Whether used to break up dense content, convey meaning quickly, or support a brand’s visual language, they’re a valuable design tool. But when icons are used as the only way to communicate important information, they become content, not just decoration. And that means they must be accessible.

Issue

Icons used as content need to:

• Be labelled for screen readers with meaningful descriptions.
• Be structured so content editors can easily manage them in the CMS.
• Avoid duplicating content or creating confusion with conflicting visual/text cues.
• If not handled carefully, screen readers may skip the icon entirely—or announce something generic like “image” or “graphic.”

Workaround

To ensure icons are accessible and manageable by content authors, we:

• Paired each icon with screen reader-only text (e.g., “Gluten-free”) using visually hidden HTML elements
• Allowed editors to add or manage this text directly in the CMS, rather than hardcoding it.
• Used ARIA roles so screen readers interpret the icons as labels, not decorative graphics.

Example

On the University of Georgia (UGA) website, we implemented this solution on the restaurant menu, where icons communicate important dietary info. By structuring the markup to include hidden descriptive text and enabling editorial control in the CMS, we made the interface both accessible and sustainable for ongoing content updates.
 

Ensuring Accessible Focus States in Dark Mode

Dark mode has become a popular design choice for modern websites. It can reduce eye strain, support user preferences, and create a sleek aesthetic. But enabling a dark mode theme adds an extra layer of complexity when it comes to accessibility—particularly for colour contrast and focus visibility.

Issue

• Colour contrast that passes in light mode may fail in dark mode, especially on hover or focus.
• Focus indicators can disappear or become too subtle against dark backgrounds.
• Keyboard users may lose visual cues for navigation if focus styling isn't tested across themes.

Workaround

• Test all state variations (default, hover, focus, active) in both light and dark modes.
• Use WCAG-compliant color contrast:
  • 4.5:1 for text
  • 3:1 for UI components (borders, outlines, focus rings)
• Customize styles to ensure visible focus indicators in dark mode (e.g., outlines, box shadows).

Takeaways: What Teams Should Watch For

Whether you’re a developer, designer, or project manager, here are a few things to keep in mind:

• Check keyboard and screen reader support early in development, especially for interactive elements.
• Don’t rely on testing tools alone. Manual testing with user scenarios are key.
• Look for alternatives and fallbacks—like offering a text version of map content or a non-dynamic option for filters.

Accessibility isn’t just about checking boxes or following rules—it’s about creating digital experiences that work for everyone. By identifying tricky features early in the process, your team can better plan, estimate, and design with inclusion in mind, reducing the need for late-stage fixes and improving usability for all.

At Evolving Web, we specialize in helping organizations meet these challenges head-on. From accessibility audits to custom component design and strategic guidance, we support teams in building websites that are not only compliant—but genuinely accessible. . If you're looking to improve your website's accessibility or tackle a specific challenge, get in touch with us.

Shopify is the biggest name in the e-commerce space, and for good reason. The platform is relatively easy to set up, performs well, and has excellent marketing. Its app marketplace is constantly growing, adding more capabilities.

For many merchants, Shopify is all they need. Going with the market leader is an obvious choice.

However, when you reach an enterprise scale, with requirements for B2B commerce and increased operational complexity, the story becomes quite different. Shopify says they offer B2B capabilities at scale, and when you’re subjected to their marketing and advertised track record, it's easy to start nodding your head to the beat of their tune.

Let’s dive into the true cost of Shopify Plus. Reading this will help you ask the right questions and better equip you to judge the answers.

The Shopify Plus Sales Machine

When Shopify's enterprise sales team comes knocking, they arrive with a compelling story. They position Shopify Plus as the solution to all your B2B woes: lower total cost of ownership, enterprise features without enterprise overhead, and the promise that migrating to Shopify Plus will lead to a conversion rate boom.

But often these promises are unrealistic. The pitch typically centers around three key pillars that deserve closer scrutiny.

The conversion rate promise

Shopify's sales pitch often includes dramatic claims about conversion improvements—sometimes suggesting compounding monthly increases that would theoretically give you a 55% conversion rate within six months.

Great month this month, tricky questions answered in Slack, via screenshare, and at Tech Group Drop-in. I'm feeling energised, read on, friends ...

An extraordinary opportunity exists to support Drupal CMS, boost your organisation's credits, and bring one of the leading minds behind Drupal CMS directly into your organization. 

We're seeking sponsors for Cristina Chumillas, the UX and Product Design Lead for Drupal CMS, who has been defining and driving the product direction since the Starshot initiative started in May 2024.

We were lucky to have Cristina engaged in this role full-time for seven months, thanks to Lullabot. Now we're looking to extend this to ensure we can deliver on the strategy for Drupal CMS 2.0 and beyond.

Why Core Contributors Are Business Game-Changers

The real value of this sponsorship goes beyond supporting Drupal—it's about what core contributors can do for your business.

"Working with a core contributor is like having a superhero on your team,” explains Pam Baronne, CTO at Technocrat and Drupal CMS Product Owner. 

"There should be an absolute premium on hiring core contributors. They aren’t just an asset to Drupal -- their skill, knowledge, and connections make them incredibly valuable to your company”.

Sponsoring a member of the Drupal CMS leadership team ensures your organization is not just prepared for what's coming, but also has the insider insight to help position you in the shifting market. 

Cristina can bring a depth of experience to your organization that is hard to match. Your sponsorship earns you contribution credits directly, boosting your Drupal Certified Partner ranking. Additionally, she can mentor your team on Drupal contribution, building expertise that elevates your company's productivity as well as your standing in the community. 

Meet Cristina - The Designer-Developer Leading Drupal's Transformation

As a designer who later learned front-end development and specializes in Drupal, Cristina brings a diverse range of skills to the role. She has been a core contributor for many years. She joined the Core Leadership Team as a front-end framework manager in 2021, and was recently also appointed as a core UX Manager. Cristina has been coordinating key design and UX initiatives in Drupal since 2017, most recently with the new Navigation in Drupal 11.
Based in Barcelona, Cristina is also active in organising the local community as well as DrupalCon. She will be a featured speaker at DrupalCon Vienna and (pending sponsorship) DrupalCon Nara as well.

The vision for Drupal CMS as a tool for marketers, designers, and content creators requires deep expertise in user experience design—exactly what Cristina brings to the role.

Flexible Engagement Options

The structure of the sponsorship engagement is flexible, and we are open to offers: 

• Full or partial sponsorship
• Project-based arrangements for specific milestones
• Part-time combinations of Drupal work with your business needs
• Custom arrangements tailored to your goals
   

Ready to add a Drupal superhero to your team?

We're open to alternative arrangements as well, so if you are interested in learning more about this opportunity, please fill in this sponsorship interest form and we will be in touch.

Drupal 7 was released in 2011 and has been the foundation of many websites for years. However, in the world of technology, 14 years is almost an eternity – during this time, Drupal has undergone a huge evolution. Today, the latest version, Drupal 11, is a modern system based on current coding standards and offering features that were once only a dream. In this article, we will look at the key differences between Drupal 7 and Drupal 11. If you last worked with Drupal years ago (e.g., with version 6 or 7), prepare yourself for the "wow" effect – Drupal 11 is a whole new experience.