Why the Machine Might Be Better at This Than We Are. There is an uncomfortable truth that most of us in product have quietly acknowledged but rarely say out loud: the majority of websites built by human developers and designers fail basic accessibility checks. Not because the people building them are careless or indifferent, but because accessibility is genuinely hard to get right consistently, it requires a specific kind of sustained discipline that competes with deadlines, budgets, and the relentless pressure to ship. When I started exploring what it would actually look like to hand markup generation over to an AI layer in our product, I expected to spend most of my time worrying about quality, consistency, and brand fidelity. What I did not expect was that the AI would, in several measurable ways, produce more accessible output than our human builders had been producing for years. That realization changed how I think about the entire product roadmap. ---
The Human Error Problem in Accessibility. Before making the case for AI-generated markup, it is worth being honest about the baseline we are comparing against. Accessibility errors in human-built interfaces tend to cluster around a handful of repeating failures. Heading hierarchies that jump from an `h1` directly to an `h4` because a designer chose a visual style rather than a semantic level. Images without meaningful `alt` text, or worse, `alt` attributes stuffed with keywords for SEO reasons. Interactive elements built from `div` tags that a keyboard user can never reach. Color combinations chosen because they look sophisticated in a Figma mockup that turn out to have a contrast ratio of 2.8:1 against a white background, well below the WCAG AA requirement of 4.5:1 for normal text. These are not edge cases. They are the norm. And they are the norm not because developers and designers are bad at their jobs but because accessibility is the kind of requirement that demands attention at every single decision point. It is easy to remember on day one of a project. It is much harder to remember at 11pm on the day before a launch when you are tweaking the color of a promotional banner. AI-generated markup does not get tired. It does not forget. And when it is trained and constrained correctly, it applies the same rules with the same rigor every single time. ---
Semantic HTML as a Default, Not an Afterthought. One of the first things I noticed when reviewing the markup our AI layer was producing was how consistently it reached for meaningful HTML elements rather than generic containers. Where a human builder under time pressure might drop a navigation menu into a series of `div` elements because it is faster and still looks correct in the browser, the AI would output a `nav` element wrapping a `ul` with properly structured `li` items. This matters more than it might appear. Semantic HTML is the foundation that assistive technologies build on. Screen readers use landmark elements to let users jump around a page efficiently. A user who is blind navigating a page full of `div` containers is navigating a featureless field. A user navigating a page built with `header`, `main`, `nav`, `aside`, and `footer` elements has a structured map of the interface handed to them automatically. The AI does this not because it has a philosophical commitment to accessibility but because when we define the rules correctly at the product level, correct semantic structure becomes the path of least resistance in the generation process. We are essentially encoding the right behavior into the default output rather than relying on individual contributors to remember to do the right thing. This is a meaningful shift in how I think about accessibility in product development. Instead of treating it as a checklist that gets applied after something is built, we are baking it into the generation process itself. The accessible version is not the extra step. It is simply what gets produced. ---
Heading Hierarchies That Actually Communicate Structure. Heading hierarchy is one of those things that sounds simple and turns out to be surprisingly difficult to get right at scale. The rule is straightforward: a page should have one `h1` that describes its primary purpose, followed by `h2` elements for major sections, `h3` elements for subsections within those, and so on. The hierarchy should reflect the actual structure of the content, not the visual appearance that a designer wanted to achieve. In practice, human-built sites routinely violate this. The violations often come from the gap between design tools and production markup. A designer specifies text sizes and weights visually. A developer, translating that into HTML, picks heading levels based on how they look by default rather than what they mean semantically. The result is heading structures that are coherent visually but incoherent semantically, which means screen reader users navigating by headings encounter a confusing or misleading outline of the page. When an AI generates markup from a content structure, it can apply heading hierarchy rules programmatically. If the product is given information about the content hierarchy — this is a page title, these are section headers, these are subsection labels — it can output the correct heading levels consistently. The visual presentation can then be handled entirely through CSS, completely independent of the semantic meaning of the elements. What I found particularly interesting in practice was that this also improved our content quality over time. When heading structure is automatically enforced, content creators receive immediate feedback when they try to create a visual hierarchy that does not match a logical content hierarchy. The constraint becomes generative. It pushes people toward clearer thinking about how their content is actually organized. ---
ARIA Attributes Applied Where They Should Be. ARIA — Accessible Rich Internet Applications — is a specification that exists to fill the gaps where HTML semantics are not sufficient to describe complex interactive patterns. Used correctly, ARIA attributes give assistive technologies the information they need to describe dynamic content, custom widgets, and state changes to users who cannot perceive those things visually. Used incorrectly, ARIA makes things worse. There is a well-worn principle in accessibility work that no ARIA is better than bad ARIA. An element with an incorrect `role` attribute or a missing required ARIA property is more confusing to a screen reader user than an element with no ARIA at all. This is why ARIA has historically been one of the most error-prone areas of accessibility implementation. The rules are complex, they are context-dependent, and they require developers to understand not just the attributes themselves but the mental model of how assistive technology users interact with different types of components. AI generation changes the calculus here in an interesting way. When a product generates a modal dialog component, it does not need to remember to add `role="dialog"`, `aria-modal="true"`, `aria-labelledby` pointing to the dialog title, and focus management that traps keyboard navigation within the dialog while it is open. All of that can be part of the template that the AI renders every time a modal is created. The developer or designer requesting the modal specifies what content it should contain. The accessible implementation is automatic. The same applies to more nuanced patterns. Accordion components with properly toggled `aria-expanded` attributes. Tab interfaces with correct `role="tablist"`, `role="tab"`, and `role="tabpanel"` relationships. Form fields with `aria-describedby` attributes linking them to their validation error messages. Custom dropdown menus that communicate their expanded state to assistive technologies. Each of these patterns has a correct ARIA implementation and several incorrect ones. For a human developer, implementing them correctly requires either significant experience or consulting documentation every time. For an AI generating from a well-defined component library, the correct implementation is simply what gets produced. The product implication is significant. We can offer complex interactive components to users who have no accessibility expertise and be confident that the output meets the standard. The knowledge is in the system rather than in the individual. ---
Color Contrast as a Calculated Property. Color contrast is perhaps the most immediately testable accessibility requirement and also one of the most commonly violated. WCAG 2.1 requires a contrast ratio of at least 4.5:1 between normal text and its background, 3:1 for large text, and 3:1 for UI components and graphical elements that convey meaning. These ratios can be calculated precisely from color values. There is no ambiguity, no interpretation required. A color combination either meets the standard or it does not. Human designers fail this check constantly, not because they do not know the rule but because visual judgment is an unreliable instrument for contrast assessment. Colors that appear high contrast in one context or on one monitor can fail the mathematical test. Colors that a designer perceives as visually distinct may still produce a ratio of 3.9:1 against white, failing the 4.5:1 requirement for normal text. Brand colors that look bold and legible in a style guide may become problematic at smaller sizes or in combinations that were not tested. AI-generated markup can enforce contrast requirements mathematically at the point of generation. When a color value is assigned to text and a background color is assigned to the containing element, the contrast ratio can be calculated automatically. If the combination fails the applicable threshold, the system can adjust — darkening or lightening one of the values just enough to meet the standard, or flagging the combination for review before it is used in production. This is a fundamentally different relationship with color than most design and development processes currently have. Instead of hoping that a designer ran the contrast checker before finalizing the palette, or that a developer noticed the small print accessibility note in the brand guidelines, the accessible version of the color relationship becomes the output by definition. From a product perspective, this also creates an interesting opportunity for user education. When a user selects a color combination that would fail contrast requirements, the system can explain why the adjustment was made. Over time, users develop a better intuitive sense of what accessible color choices look like. The AI is not just producing accessible output — it is teaching. ---
The Compounding Effect of Getting This Right at Scale. There is an argument that a skilled, accessibility-focused developer can produce better accessible markup than an AI system. I believe that argument is probably true in ideal conditions. A deeply experienced accessibility engineer who is given sufficient time, has a thorough brief, and is working without competing pressures can produce nuanced, carefully considered accessible implementation that an AI system constrained by templates and rules might not match for every edge case. But that is not the comparison that matters for most products operating at scale. The real comparison is between an AI system that produces consistently accessible output and a team of developers and designers of varying skill levels and varying familiarity with accessibility requirements, working under realistic conditions of time pressure and context switching, making hundreds of small decisions every day, some of which will be wrong. At scale, consistency wins. A product that produces markup that meets WCAG AA requirements for every component every time is more valuable from an accessibility standpoint than a product that sometimes produces excellent accessible markup and sometimes produces markup that a screen reader user cannot navigate at all. This is the product owner's argument for AI-generated accessible markup. It is not that AI is smarter than humans. It is that AI is more consistent, and consistency is what accessibility actually requires. ---
What This Means for Product Responsibility. Committing to accessible AI-generated markup is also an assumption of responsibility that I take seriously. When we tell users that the output of our product will be accessible, we are making a promise. That promise needs to be backed by testing, not just by confidence in the generation system. Automated accessibility testing needs to be integrated into the product's feedback loop. Real assistive technology testing — with screen readers, voice control software, switch access devices — needs to happen regularly and not just at initial launch. Edge cases in content that break the AI's accessible output patterns need to be identified and addressed. The AI does not eliminate the need for accessibility expertise in product development. It transforms where that expertise is applied. Instead of each individual contributor needing to hold all of the accessibility knowledge required to implement their part of a product correctly, the expertise is concentrated in the people defining the generation system itself and testing its output. The knowledge becomes part of the product rather than part of the people using it. This is a more sustainable model. Accessibility knowledge is not lost when an employee leaves. It is not inconsistently applied because some team members have had more training than others. It is not gradually eroded by the shortcuts that inevitably accumulate in codebases built under pressure. ---
The Opportunity Ahead. We are at an early point in understanding what AI-generated markup can reliably deliver from an accessibility standpoint. The wins I have described — semantic HTML, correct heading hierarchies, appropriate ARIA implementation, mathematically compliant color contrast — are real and measurable. They represent a genuine step forward compared to the baseline of human-built interfaces. But there is more to accessibility than these technical requirements. Cognitive accessibility, clear language, logical reading order, predictable navigation, content that is comprehensible at different levels of literacy — these are harder to systematize and harder to generate correctly without deep understanding of the users being served. The path forward for products built on AI-generated markup is to treat the technical accessibility wins as the foundation they are — necessary but not sufficient — and to continue investing in understanding the full range of what accessible experience means for real users. The machine can handle the contrast ratio calculation. The humans still need to care about whether the content actually serves the people it is meant to reach. That division of responsibility, I think, is the right one. Let the AI do consistently what humans do inconsistently. Keep the humans focused on what machines cannot do at all.
The Human Error Problem in Accessibility. Before making the case for AI-generated markup, it is worth being honest about the baseline we are comparing against. Accessibility errors in human-built interfaces tend to cluster around a handful of repeating failures. Heading hierarchies that jump from an `h1` directly to an `h4` because a designer chose a visual style rather than a semantic level. Images without meaningful `alt` text, or worse, `alt` attributes stuffed with keywords for SEO reasons. Interactive elements built from `div` tags that a keyboard user can never reach. Color combinations chosen because they look sophisticated in a Figma mockup that turn out to have a contrast ratio of 2.8:1 against a white background, well below the WCAG AA requirement of 4.5:1 for normal text. These are not edge cases. They are the norm. And they are the norm not because developers and designers are bad at their jobs but because accessibility is the kind of requirement that demands attention at every single decision point. It is easy to remember on day one of a project. It is much harder to remember at 11pm on the day before a launch when you are tweaking the color of a promotional banner. AI-generated markup does not get tired. It does not forget. And when it is trained and constrained correctly, it applies the same rules with the same rigor every single time. ---
Semantic HTML as a Default, Not an Afterthought. One of the first things I noticed when reviewing the markup our AI layer was producing was how consistently it reached for meaningful HTML elements rather than generic containers. Where a human builder under time pressure might drop a navigation menu into a series of `div` elements because it is faster and still looks correct in the browser, the AI would output a `nav` element wrapping a `ul` with properly structured `li` items. This matters more than it might appear. Semantic HTML is the foundation that assistive technologies build on. Screen readers use landmark elements to let users jump around a page efficiently. A user who is blind navigating a page full of `div` containers is navigating a featureless field. A user navigating a page built with `header`, `main`, `nav`, `aside`, and `footer` elements has a structured map of the interface handed to them automatically. The AI does this not because it has a philosophical commitment to accessibility but because when we define the rules correctly at the product level, correct semantic structure becomes the path of least resistance in the generation process. We are essentially encoding the right behavior into the default output rather than relying on individual contributors to remember to do the right thing. This is a meaningful shift in how I think about accessibility in product development. Instead of treating it as a checklist that gets applied after something is built, we are baking it into the generation process itself. The accessible version is not the extra step. It is simply what gets produced. ---
Heading Hierarchies That Actually Communicate Structure. Heading hierarchy is one of those things that sounds simple and turns out to be surprisingly difficult to get right at scale. The rule is straightforward: a page should have one `h1` that describes its primary purpose, followed by `h2` elements for major sections, `h3` elements for subsections within those, and so on. The hierarchy should reflect the actual structure of the content, not the visual appearance that a designer wanted to achieve. In practice, human-built sites routinely violate this. The violations often come from the gap between design tools and production markup. A designer specifies text sizes and weights visually. A developer, translating that into HTML, picks heading levels based on how they look by default rather than what they mean semantically. The result is heading structures that are coherent visually but incoherent semantically, which means screen reader users navigating by headings encounter a confusing or misleading outline of the page. When an AI generates markup from a content structure, it can apply heading hierarchy rules programmatically. If the product is given information about the content hierarchy — this is a page title, these are section headers, these are subsection labels — it can output the correct heading levels consistently. The visual presentation can then be handled entirely through CSS, completely independent of the semantic meaning of the elements. What I found particularly interesting in practice was that this also improved our content quality over time. When heading structure is automatically enforced, content creators receive immediate feedback when they try to create a visual hierarchy that does not match a logical content hierarchy. The constraint becomes generative. It pushes people toward clearer thinking about how their content is actually organized. ---
ARIA Attributes Applied Where They Should Be. ARIA — Accessible Rich Internet Applications — is a specification that exists to fill the gaps where HTML semantics are not sufficient to describe complex interactive patterns. Used correctly, ARIA attributes give assistive technologies the information they need to describe dynamic content, custom widgets, and state changes to users who cannot perceive those things visually. Used incorrectly, ARIA makes things worse. There is a well-worn principle in accessibility work that no ARIA is better than bad ARIA. An element with an incorrect `role` attribute or a missing required ARIA property is more confusing to a screen reader user than an element with no ARIA at all. This is why ARIA has historically been one of the most error-prone areas of accessibility implementation. The rules are complex, they are context-dependent, and they require developers to understand not just the attributes themselves but the mental model of how assistive technology users interact with different types of components. AI generation changes the calculus here in an interesting way. When a product generates a modal dialog component, it does not need to remember to add `role="dialog"`, `aria-modal="true"`, `aria-labelledby` pointing to the dialog title, and focus management that traps keyboard navigation within the dialog while it is open. All of that can be part of the template that the AI renders every time a modal is created. The developer or designer requesting the modal specifies what content it should contain. The accessible implementation is automatic. The same applies to more nuanced patterns. Accordion components with properly toggled `aria-expanded` attributes. Tab interfaces with correct `role="tablist"`, `role="tab"`, and `role="tabpanel"` relationships. Form fields with `aria-describedby` attributes linking them to their validation error messages. Custom dropdown menus that communicate their expanded state to assistive technologies. Each of these patterns has a correct ARIA implementation and several incorrect ones. For a human developer, implementing them correctly requires either significant experience or consulting documentation every time. For an AI generating from a well-defined component library, the correct implementation is simply what gets produced. The product implication is significant. We can offer complex interactive components to users who have no accessibility expertise and be confident that the output meets the standard. The knowledge is in the system rather than in the individual. ---
Color Contrast as a Calculated Property. Color contrast is perhaps the most immediately testable accessibility requirement and also one of the most commonly violated. WCAG 2.1 requires a contrast ratio of at least 4.5:1 between normal text and its background, 3:1 for large text, and 3:1 for UI components and graphical elements that convey meaning. These ratios can be calculated precisely from color values. There is no ambiguity, no interpretation required. A color combination either meets the standard or it does not. Human designers fail this check constantly, not because they do not know the rule but because visual judgment is an unreliable instrument for contrast assessment. Colors that appear high contrast in one context or on one monitor can fail the mathematical test. Colors that a designer perceives as visually distinct may still produce a ratio of 3.9:1 against white, failing the 4.5:1 requirement for normal text. Brand colors that look bold and legible in a style guide may become problematic at smaller sizes or in combinations that were not tested. AI-generated markup can enforce contrast requirements mathematically at the point of generation. When a color value is assigned to text and a background color is assigned to the containing element, the contrast ratio can be calculated automatically. If the combination fails the applicable threshold, the system can adjust — darkening or lightening one of the values just enough to meet the standard, or flagging the combination for review before it is used in production. This is a fundamentally different relationship with color than most design and development processes currently have. Instead of hoping that a designer ran the contrast checker before finalizing the palette, or that a developer noticed the small print accessibility note in the brand guidelines, the accessible version of the color relationship becomes the output by definition. From a product perspective, this also creates an interesting opportunity for user education. When a user selects a color combination that would fail contrast requirements, the system can explain why the adjustment was made. Over time, users develop a better intuitive sense of what accessible color choices look like. The AI is not just producing accessible output — it is teaching. ---
The Compounding Effect of Getting This Right at Scale. There is an argument that a skilled, accessibility-focused developer can produce better accessible markup than an AI system. I believe that argument is probably true in ideal conditions. A deeply experienced accessibility engineer who is given sufficient time, has a thorough brief, and is working without competing pressures can produce nuanced, carefully considered accessible implementation that an AI system constrained by templates and rules might not match for every edge case. But that is not the comparison that matters for most products operating at scale. The real comparison is between an AI system that produces consistently accessible output and a team of developers and designers of varying skill levels and varying familiarity with accessibility requirements, working under realistic conditions of time pressure and context switching, making hundreds of small decisions every day, some of which will be wrong. At scale, consistency wins. A product that produces markup that meets WCAG AA requirements for every component every time is more valuable from an accessibility standpoint than a product that sometimes produces excellent accessible markup and sometimes produces markup that a screen reader user cannot navigate at all. This is the product owner's argument for AI-generated accessible markup. It is not that AI is smarter than humans. It is that AI is more consistent, and consistency is what accessibility actually requires. ---
What This Means for Product Responsibility. Committing to accessible AI-generated markup is also an assumption of responsibility that I take seriously. When we tell users that the output of our product will be accessible, we are making a promise. That promise needs to be backed by testing, not just by confidence in the generation system. Automated accessibility testing needs to be integrated into the product's feedback loop. Real assistive technology testing — with screen readers, voice control software, switch access devices — needs to happen regularly and not just at initial launch. Edge cases in content that break the AI's accessible output patterns need to be identified and addressed. The AI does not eliminate the need for accessibility expertise in product development. It transforms where that expertise is applied. Instead of each individual contributor needing to hold all of the accessibility knowledge required to implement their part of a product correctly, the expertise is concentrated in the people defining the generation system itself and testing its output. The knowledge becomes part of the product rather than part of the people using it. This is a more sustainable model. Accessibility knowledge is not lost when an employee leaves. It is not inconsistently applied because some team members have had more training than others. It is not gradually eroded by the shortcuts that inevitably accumulate in codebases built under pressure. ---
The Opportunity Ahead. We are at an early point in understanding what AI-generated markup can reliably deliver from an accessibility standpoint. The wins I have described — semantic HTML, correct heading hierarchies, appropriate ARIA implementation, mathematically compliant color contrast — are real and measurable. They represent a genuine step forward compared to the baseline of human-built interfaces. But there is more to accessibility than these technical requirements. Cognitive accessibility, clear language, logical reading order, predictable navigation, content that is comprehensible at different levels of literacy — these are harder to systematize and harder to generate correctly without deep understanding of the users being served. The path forward for products built on AI-generated markup is to treat the technical accessibility wins as the foundation they are — necessary but not sufficient — and to continue investing in understanding the full range of what accessible experience means for real users. The machine can handle the contrast ratio calculation. The humans still need to care about whether the content actually serves the people it is meant to reach. That division of responsibility, I think, is the right one. Let the AI do consistently what humans do inconsistently. Keep the humans focused on what machines cannot do at all.