"Shifting left" on accessibility means baking inclusive design into the earliest stages of your project—before development even begins. The term comes from software development lifecycles, where early-phase activities like planning and design are on the "left" of a project timeline. Unfortunately, accessibility often gets shoved to the "right," tacked on during QA or just before launch. This leads to rushed fixes, poor user experiences, and unnecessary costs.
Imagine writing a book without organizing chapters or checking the font size before hitting print. That’s what it’s like to ignore accessibility until the end. When you shift left, you not only build a better experience for all users, but you also reduce rework and unlock smarter, more innovative designs.
Shifting left is about collaboration
A successful website project isn’t a linear train ride from content to design to development. It’s a dynamic, collaborative ecosystem that means everyone contributes.
- Strategists ensure content is easy to find.
- Designers prioritize color contrast, readable typography, and interactive elements.
- Back-end developers support accessible content structures and accessible interaction.
- Front-end developers implement semantic markup and accessible UI components.
- QA testers verify functionality across assistive devices.
- DevOps engineers integrate automated accessibility checks into the workflow.
- Technical project managers: keep accessibility visible and prioritized.
Accessibility should be part of every conversation—from kickoff to QA.
Accessibility and project management
Technical project managers prioritize accessibility from the start. They align early by documenting assumptions, setting baseline requirements, and getting buy-in from the whole team. By including accessibility in tickets and “definition of done” criteria, it becomes a natural part of the workflow.
When conflicts arise
Stakeholders may question accessibility requirements. Listen to their concerns, acknowledge their priorities, and advocate for inclusive solutions. If accessibility is deprioritized, document the risks—legal, ethical, and financial—so everyone understands the impact.
Compromise may be necessary. Push for easy wins while tracking deferred items for future improvements, and refer back to early agreements.
Connect accessibility to what matters most: your goals
In government and higher education, accessibility isn’t optional—it’s the law. Failing to meet accessibility standards can mean legal trouble and missed funding opportunities.
But even if you’re not in a regulated industry, accessibility still makes smart business sense. The more usable your site is, the more it supports your goals:
- SEO boost: Search engines reward clean, accessible site structures.
- Better conversions: Faster, easier-to-use websites help more people take action.
- Wider reach: The CDC reports that 1 in 4 adults has a disability. That’s a massive audience you don’t want to ignore.
Accessibility isn’t just a checkbox; it’s a growth strategy. Tie it to the outcomes your stakeholders care about, and it becomes an easy yes.
Accessibility and content strategy
Content strategy and accessibility go hand in hand, and both should be part of a project from day one. After all, the main purpose of a website is to share information. Making sure that content is easy to find, understand, and use is essential to delivering a great user experience, which starts with a solid strategy that puts accessibility front and center.
Why logical structure matters
A well-organized site is easier for everyone to navigate. When pages are connected in a logical way, the navigation makes sense, and keywords reflect what real people are searching for, you’re helping users find what they need faster. That’s not just good UX—it’s accessibility in action.
If someone can’t find the content they need, it’s essentially inaccessible. That’s why elements like straightforward navigation, page titles, breadcrumbs, and sitemaps aren’t just helpful extras; they’re accessibility features. They also support SEO. Search engines appreciate it when your site is structured for people, too.
Content design and accessibility
Page-level structure is just as important as overall site organization. This is where content strategy overlaps with content design and where thoughtful decisions can have a big impact on accessibility. Key practices include:
- Using plain language: Write in a clear, straightforward way to make content accessible to a wide range of reading levels—and easier to translate.
- Explaining technical terms: Offer definitions, glossaries, or simple explanations to help users understand complex content.
- Creating logical reading order: Break up long blocks of text with clear subheadings, paragraph breaks, and bulleted lists to improve readability and scannability—for both users and search engines.
- Writing inclusively: Use language that respects cultural differences and avoids harmful or polarizing terms so your content is welcoming to all audiences.
A good content strategy organizes your message and ensures that it is available, understandable, and usable by everyone who needs it.
Accessibility during the design phase
Designers play a big role in shaping a website’s accessibility, often before a single line of code is written. The design phase is the perfect time to remove barriers and ensure everyone can easily access the information they need.
By “shifting left,” you set the entire project up for success. Here are key accessibility considerations when designing a system:
- Text readability: Choose web-friendly fonts, use clear typographic hierarchy, and ensure heading sizes and spacing support easy reading across devices. Good visual rhythm helps everyone process content more easily.
- Color contrast: Make sure text and UI elements stand out clearly from their backgrounds. Follow or exceed WCAG AA standards to ensure readability for users with low vision or color blindness.
- Background design: Avoid backgrounds that create visual noise or vibration. Subtle patterns or images can add flair, but they shouldn’t compete with or obscure your content.
- Interactive elements: Buttons and links should be clearly labeled and well-spaced. Include all interactive states—default, hover, focus, active—and use more than just color to show when something is clickable. For example, linked headings should have clear visual indicators beyond color alone.
- Touch Targets: Make sure links and buttons are easy to tap, especially on mobile. The bare minimum is 24x24 pixels, but aiming for 48x48 is best for usability.
- Data Visualization: Tables, charts, and graphs should include descriptive captions. For sortable tables, provide visual cues for sort direction so users can quickly understand what they’re seeing.
- Motion Sensitivity: Some users are sensitive to movement. To make the experience more comfortable, offer reduced motion settings and pause/play controls for auto-playing videos or animations.
- Consistency: Keep visual styles consistent across the site. A predictable layout helps users navigate with confidence, especially those using assistive technologies.
- Accessibility Annotations: Include notes for developers about accessibility-related design choices, like heading levels or focus order. This ensures your intent carries through to the final build.
Designing with accessibility in mind isn’t just a best practice—it’s essential for building inclusive, effective digital experiences from the ground up.
More tips for designing for accessibility
Accessibility in development and QA
Accessibility doesn't stop with design. It needs to be part of development and quality assurance, too. Developers are often responsible for what we call "unspoken" or "implied" accessibility features. These include things like:
- Skip links to help users bypass repetitive content
- Ensuring the site is fully navigable by keyboard
- Keeping touch targets large enough for users on any device
If you're using a CMS like Drupal, many accessibility features are built-in. However, developers must be careful not to disable or override those helpful defaults.
Front-end responsibilities
Front-end developers shape the experience users see and interact with, so their role in accessibility is critical. When accessibility has already been considered in design, implementation becomes much smoother. Here's what front-end devs should focus on:
- User control: Give users the option to pause animations or motion. Not everyone wants or needs those effects.
- Semantic structure: Use meaningful HTML elements and supplement with ARIA roles only when necessary. This helps assistive tech understand your content.
- Keyboard navigation: Make sure everything works without a mouse—maintain a logical tab order and clear focus states.
- Menus and navigation: Menus, dropdowns, and modals should all be navigable by the keyboard and assistive tools. For Drupal sites, consider reusing Olivero's menu.
- Interactive elements: Implement accessible markup for tables, slideshows, toggles, and other interactive elements that work with assistive technologies.
- Forms: Clearly label inputs, show which fields are required, include helpful error messages, and use proper validation. Read more about accessible forms.
- SVGs: Ensure SVG files follow best practices in tag markup structure, including brief but descriptive <title> tags for screen reader compatibility.
Back-End responsibilities
Back-end developers build the systems that power the site. Their code often generates the markup users interact with, so accessibility still matters. Key responsibilities include:
- Writing secure, performant code that outputs clean markup
- Keeping codebases updated and patched
- Documenting work for future maintainers
- Writing automated tests, including accessibility tests, when possible (more on this below)
Testing and QA for accessibility
Every pull request or release should include some level of accessibility check. Don’t wait until the test ends. Shifting left here means building accessibility into your workflows:
- Use tools like Tugboat to preview changes in a live environment.
- Free tools like aXe integrate with testing frameworks like Playwright.
- Run Lighthouse accessibility audits in Chrome for quick feedback.
You don’t have to test every ticket, but you should test consistently. If you follow a sprint cadence, a full accessibility review every 2–4 weeks could be a good rhythm. Definitely review before major releases.
Accessibility concerns for client training and content entry
Without proper training and constant vigilance, content authors can create accessibility problems for a website. Errors compound as they insert text, media, and other documents.
Some common mistakes we’ve seen:
- Non-hierarchical ordering of headings. H3 tags should be under H2 tags, for example.
- Improper alt text or no alt text on images.
- Burning text onto images.
- Inserting images into tables to achieve a certain layout.
- Improper color contrast for sites that allow authors to pick colors for elements.
Training content authors to avoid accessibility issues
Without proper training and constant vigilance, content authors can create accessibility problems for a website. Errors compound as they insert text, media, and other documents.
Some common mistakes we’ve seen:
- Non-hierarchical ordering of headings. H3 tags should be under H2 tags, for example.
- Improper alt text or no alt text on images.
- Burning text onto images.
- Inserting images into tables to achieve a certain layout.
- Improper color contrast for sites that allow authors to pick colors for elements.
Global scanning tools like Dubbot or Acquia Optimize can help authors see how their work impacts site performance and accessibility. We’ve also worked within an organization's own processes (or helped them create a process) to evaluate, assign, and track changes toward greater accessibility. Shared spreadsheets help with visibility, review, and sign-off approvals for content.
Sites with copied-and-pasted text, such as from a Google or Word doc, sometimes need to be rehabilitated. However, authors need to be trained in what to look for. Embedded documents face similar hurdles. We’ve experienced bundles of uploaded PDFs that never received accessibility remediation. Establish a disciplined approach to tracking the state of an individual PDF (i.e., has this document been evaluated for accessibility? Yes/No).
We’ve experimented with editorial tools such as editoria11y inside the WYSIWYG editor. This tool reminds the author to review common accessibility flags. It has a Drupal module and a WordPress plugin. Lighthouse is a free and easy extension inside the Chrome browser that runs a series of audits, including accessibility checks.
Cultivate your accessibility champions
Accessibility reviews and expertise can be inserted at different points in the content process. The person's title doesn’t matter so much as their knowledge and willingness to champion accessibility. We have accessibility specialists who are strategists, designers, developers, and project managers. However, it helps for an internal accessibility champion to have some level of authority for a project so that accessibility concerns get the weight they deserve.
Accessibility after project launch and beyond
The accessibility of a website is subject to entropy and requires vigilance throughout its entire lifecycle. Some of the same checks and balances implemented earlier should continue as bugs are fixed and new features are released.
This is the point where accessibility regressions can occur. Excitement dies down. Attention to detail can fade. Stakeholders are pulled away to other projects, and one of them might be the accessibility champion who made accessibility concerns a high priority. Make sure the responsibility is not dropped somewhere, forgotten in the wasteland. Keep accessibility in the feedback loop for any changes made to the website.
If you have any marketing or SEO initiatives, someone on that team might be a good candidate to continue addressing accessibility concerns. Marketers don’t want to turn away potential customers with an inaccessible website, and good accessibility often improves SEO.
Tracking accessibility scores
One of our clients set up an analytics dashboard that centralized the data for all websites, including aggregate accessibility scores. If a score begins to drop, people know. The dashboard isn’t a replacement for manual testing, but it does help keep accessibility at the top of the organization's mind, which is sometimes half the battle.
Onboarding new CMS users
The State of Iowa has a training website for its digital experience to help onboard new content authors and be an ongoing resource for current staff. It has CMS tutorials, style guides, content quality checklists, accessibility best practices, and more.
Timeline and budget impact of early accessibility integration
“We don’t have time” is a common excuse given and a reason why accessibility concerns get pushed toward the end of a project. Digital work gives the illusion of easy change, that you can paste over problems later. Sometimes, you can. And one of the benefits of a digital medium is how easy it is to change and add content.
However, this reasoning reveals its flaws when placed in a different context.
“We don’t have time to repair the cracks in the foundation. Start framing the drywall.”
“We don’t have time to measure the size of the window frame twice. Just make the window.”
Fixing problems early in a project is always easier and cheaper than letting them fester until the end. When you shift left on accessibility, designs are tweaked before developers implement them. The UX for content authors is crafted to help prevent inaccessible content from ballooning out of control, preventing costly remediation later on. Every change a developer submits maintains best practices for things like aria attributes and performance, keeping technical debt low.