Accessibility for Developers: 10 Barriers to Inclusive Code

Front-end developers, full-stack engineers, and CMS implementers consistently deprioritise accessibility, often for the same reasons. This knowledge base names those reasons honestly, then presents the evidence-based reality behind each one.

These barriers appear in code reviews, sprint retrospectives, pull request comments, and CMS training sessions across every industry. The good news: the most common WCAG failures have simple technical fixes that require no specialist knowledge, only the willingness to apply them.

Frameworks & Tools

"The framework or component library handles accessibility"

"We use Material UI / Bootstrap / Ant Design. It's all accessible out of the box."

Component libraries provide accessible building blocks, but only when they are configured and composed correctly. A <Button> component from a library is accessible when used as a button. Wrapping a <div> in it, using it as a link, or suppressing its default behaviour without keyboard handling produces inaccessible output regardless of the library used.

The reality

Frameworks output the HTML you author. A <div onClick> is not a button, it has no keyboard role, no Enter/Space handling, and no announced name. A <span> is not a heading. React, Vue, and Angular are accessibility-neutral: they generate whatever the developer writes. The responsibility for semantic correctness is always the developer's, not the framework's.

Related: 4.1.2 Name, Role, Value 2.1.1 Keyboard

Frameworks & Tools

"I skip the accessibility fields in our CMS"

"The alt text and heading level fields are optional. I leave them blank, it's not blocking anything."

Every CMS that prompts for alt text, heading level, table summary, or link label is surfacing a WCAG requirement to the person best positioned to fulfil it. Leaving these fields blank is not a neutral act, it creates a concrete barrier on every page where that content appears, affecting every screen reader user who encounters it.

The reality

Missing alt text (WCAG 1.1.1, Level A) affected 53.1% of the top one million websites in 2026 (WebAIM). Missing form labels (WCAG 3.3.2, Level A) affected 51%. Empty links (WCAG 2.4.4, Level A) affected 46.3%. These are the most prevalent failures on the web, and all of them appear in CMS content, authored by people who thought the fields were optional. They are optional for the CMS; they are not optional for WCAG.

Related: 1.1.1 Non-text Content 2.4.4 Link Purpose 3.3.2 Labels or Instructions

Testing & Process

"Automated testing gives us 0 violations, we're done"

"We run axe on every pull request. We're clean. Nothing to fix."

Automated accessibility testing tools, axe, Lighthouse, WAVE, SiteImprove, are valuable and should be used. But they detect approximately 30–40% of WCAG 2 failures. The majority of barriers require human judgement: whether alt text is meaningful, whether reading order makes sense, whether a keyboard interaction is intuitive, whether an error message is actually helpful.

The reality

A score of 0 automated violations is a floor, not a ceiling. No automated tool can assess whether alt="image12345_final_v3.jpg" conveys the meaning of the image. No tool can verify that a modal's focus management is correct, or that a carousel is operable with a keyboard in practice. Automated testing is the first step, not the last. Pair it with keyboard testing, screen reader spot checks, and periodic expert audit.

Related service: Accessibility Audit User Testing

Audience & Business

"Keyboard navigation is an edge case"

"Most users have a mouse. Keyboard support is for power users and blind people, that's a small audience."

Keyboard operability (WCAG 2.1.1) is a Level A requirement, the minimum baseline. It is not an optional enhancement. The keyboard is the primary input method for screen reader users, switch access users, users with tremors or motor impairments, and power users who prefer it. It is also the foundation for voice control (Dragon NaturallySpeaking navigates by keyboard equivalent commands).

The reality

Every interactive element that is unreachable by keyboard is a WCAG Level A failure. The keyboard test takes under five minutes: open your page, disconnect the mouse, and try to complete every user task using only Tab, Shift+Tab, Enter, Space, and arrow keys. If you get stuck anywhere, you have a failure. This test requires no specialist knowledge and no tools, just a mouse cable and five minutes.

Related: 2.1.1 Keyboard 2.1.2 No Keyboard Trap 2.4.3 Focus Order

Frameworks & Tools

"I'll add ARIA attributes to fix the accessibility"

"I wrapped it in role='region' and gave it an aria-label. That should cover it."

ARIA (Accessible Rich Internet Applications) is a powerful tool for communicating semantics that HTML cannot express natively. It is also one of the most commonly misapplied specifications in web development. Incorrectly applied ARIA creates barriers that did not previously exist, it does not fix them.

The reality

The first rule of ARIA is: if a native HTML element or attribute exists with the semantics and behaviour you need, use it instead of ARIA. A <button> is better than <div role="button"> because the native element includes keyboard handling, focus behaviour, and implicit role for free. Common misapplication examples: aria-hidden="true" on visible interactive content (traps keyboard users), duplicate aria-label values on similar elements, and role="button" on a <div> without tabindex="0" and keydown handling.

Related: 4.1.2 Name, Role, Value 1.3.1 Info and Relationships

Testing & Process

"I don't have a screen reader to test with"

"We'd need to buy JAWS and spend weeks learning it. Not realistic for our team."

Screen reader testing is the single most effective way to catch the accessibility failures that automated tools miss: missing or meaningless alt text, illogical reading order, unlabelled form fields, inaccessible modals, and broken SPA navigation. The perceived cost barrier is real, but it has not been true for years.

The reality

Free screen readers available right now: VoiceOver (built into every Mac, iPhone, and iPad, press Cmd+F5); NVDA (free download for Windows, nvaccess.org); Narrator (built into Windows 10/11); ChromeVox (free Chrome extension). Learning the six navigation commands required for basic testing (Tab, arrow keys, H for headings, F for form fields, B for buttons, G for graphics) takes under 30 minutes. This is the highest-return 30 minutes any developer can invest in accessibility.

"Accessibility tickets live in the backlog, not the current sprint"

"We have features to ship. Accessibility has a card in the backlog for next quarter."

Accessibility tickets in a backlog without a committed sprint are a deferral mechanism, not a plan. The pattern is consistent across teams: the backlog item is perpetually deprioritised in favour of features, the codebase grows on inaccessible foundations, and the eventual remediation cost multiplies with every release.

The reality

Retrofitting accessibility into code costs an estimated 10–20x more than building it correctly in the first sprint. WCAG 2 Level AA is a legal requirement for Australian Government agencies under the Digital Experience Policy, with a compliance deadline of 1 January 2026. It is an increasing procurement requirement for enterprise buyers across all sectors. Treating accessibility as optional backlog work creates legal risk, not just technical debt.

Related service: Consulting & Strategy Developer Training

Process & Responsibility

"The design didn't spec it, so I built what I was given"

"If accessibility was important, the designer would have specced it. I implement what the Figma file says."

Design files communicate visual intent, layout, colour, typography. They cannot communicate semantic HTML structure, ARIA roles, keyboard event handling, or focus management. These are implementation decisions that live entirely in code. A design file that is silent on accessibility does not relieve the developer of the responsibility to implement correct semantics.

The reality

The developer decides whether an interactive element is a <button> or a <div>. The developer decides whether a form field has an associated <label>. The developer decides whether an error message uses role="alert". The developer decides whether a modal traps focus correctly. None of these decisions appear in a design file, they are all developer responsibilities. When design and development share this understanding, accessibility improves; when developers wait for designers to specify it all, it never gets done.

Related: 1.3.1 Info and Relationships 3.3.1 Error Identification 4.1.2 Name, Role, Value

Frameworks & Tools

"WCAG doesn't really apply to our single-page app"

"It's a React SPA, the old WCAG rules were written for static HTML pages. They don't map."

WCAG applies to all web content that users encounter in a browser, regardless of the underlying framework or rendering method. Single-page applications introduce specific patterns, client-side routing, dynamic content updates, modal management, that create accessibility failures not present in server-rendered pages.

The reality

SPA-specific failures include: route changes that don't move keyboard focus (leaving screen reader users on the previous page's heading), fetch-loaded content that is invisible to screen readers without aria-live regions, modals that don't trap focus, and infinite scroll without keyboard alternatives. WCAG 2.4.3 Focus Order (A), 4.1.3 Status Messages (AA, WCAG 2.1), and 2.4.4 Link Purpose address these directly. Every major JavaScript framework has accessibility guidance that handles these patterns, they are not new problems.

Related: 2.4.3 Focus Order 4.1.3 Status Messages 2.4.4 Link Purpose

Knowledge & Learning

"Accessibility is too complex, I'll get ARIA wrong and make it worse"

"I don't know enough about ARIA and screen readers. I'd rather not touch it and make things worse."

Analysis paralysis around accessibility is understandable, ARIA is a large, nuanced specification, and misapplication is a genuine risk. But this concern disproportionately raises the perceived complexity of accessibility as a whole, when in reality the most impactful fixes require no ARIA knowledge at all.

The reality

The six most common WCAG failures on the web, low contrast text, missing alt text, missing form labels, empty links, empty buttons, and missing document language (WebAIM Million, 2026), are all fixable with basic HTML. Not one of them requires ARIA. Start there. Fix these six issues in your codebase and you will have addressed the majority of barriers affecting your users. ARIA expertise is valuable for complex interactive patterns, modals, accordions, custom dropdowns, and that knowledge can be developed incrementally. The first rule of ARIA remains: use native HTML first.

Related: 1.1.1 Non-text Content 1.4.3 Contrast (Minimum) 3.1.1 Language of Page

Ready to Build Accessibility into Your Development Practice?

Our team works directly with development teams to audit, train, and embed accessibility standards from the codebase up.

Talk to Us