The comparison table block in our CMS renders a layout that designers are happy with and assistive technology can navigate properly. The visual experience and the accessible experience are both intentional, not one bolted onto the other.
This pattern applies anywhere you're using custom layouts for tabular data: pricing grids, feature comparisons, plan selectors, specification tables. If the content has rows and columns with header relationships, it needs table semantics, whether or not it uses a `<table>` element.
The effort is small. A handful of ARIA attributes on components you're already building. The impact is that a significant portion of your audience can actually use the content you spent time designing.
For service and pricing pages in particular, this is content that directly influences purchase decisions. Making it inaccessible to screen reader users isn't just an accessibility failure, it's a conversion failure.