The PDF/UA ("tagged PDF") standard was established in 2012 to add accessibility features to the PDF format using a system of tags.

The tags add semantic information to a document, "marking up" such elements as headings, lists, figures, tables and other common document idioms.

PDF/UA also offers a 'read order' feature, which allows content to be presented in a non-visual way which corresponds to the intended sequence.

These features may be created and edited using Acrobat Pro, which is good. although Acrobat Pro is currently unable to generate or accurately assess a fully compliant PDF/UA file without additional 3rd party software.
(The criteria for well-formed PDF/UA is documented by the Matterhorn Protocol. A URL to this spec may be found below. Acrobat's accessibility check does not follow this spec 100%).

The tagging and read-order features should permit 'semantic browsing' of PDF files, so that a visually impaired or dyslexic user can use a screen reader, braille device or other assistive technology to navigate a document.

Using Acrobat's "Read Aloud", a user is obliged to read every single word of every single page just to find content. They are offered no distinction between headings and body text, lists, list items, tables, figures or images even if those tags have been carefully set up by the document author.

With support for browsing via tags, a user would be able to skim quickly to the content they need, just as they already do with well-formed HTML pages in a modern browser.

Unfortunately, Acrobat Reader's accessibility features have not followed up with PDF/UA. There is currently no way to browse a tagged PDF using the tags, and there is very poor or non-existent support for assistive technology such as Apple's VoiceOver, Microsoft's Narrator, or third party ATs such as JAWS or NVDA.

Perhaps worst of all, there are no other PDF viewers on Apple's platform which communicate the PDF/UA tags to Apple's Accessibility API.

When a 'tagged PDF' is viewed in a browser, it does not generate an 'accessibility tree' - the data structure which communicates the semantic structure and content to the host accessibility API. Some of these in-browser PDF viewers come from 3rd parties, but at least one of them is offered by Adobe.

This means that even a well-formed PDF/UA is neither truly portable, nor truly accessible, making it wholly unsuitable for conformance with accessibility legislation such as Section 508.

Furthermore this could have legal consequences for Adobe's customers, who may be led to believe (by Adobe's own marketing materials and accessibility documentation) that "PDF tagging" is a legally viable way to conform to the accessibility guidelines mandated in various jurisdictions, especially including North America and the EU.

Will it take a lawsuit before Adobe acts on this shortcoming? It could be a painful, expensive and time-consuming way to address the problem.

My feature request is this: Adobe Acrobat should communicate the accessibility tags and read order in PDF/UA files to the appropriate accessibility APIs of any host system it runs on.

Until this happens, the accessibility of PDF as a whole may be described as "limited" at best. The "Read Aloud" feature offers a bare minimum of screen reader features - but is a very blunt tool, which offers a very inferior experience to users with visual impairments, dyslexia or similar disabilities.

2020 saw record numbers of accessibility lawsuits in the wake of recent legislation. Adobe should consider the legal risk of the current situation very carefully (especially the legal risk to Adobe's own customers), and perhaps revise its Acrobat marketing and documentation to clarify the shortcomings.

A "reference quality" PDF/UA file may be found at https://www.pdfa.org/wp-content/uploads/2021/04/Matterhorn-Protocol-1-1.pdf ... which happens to be the documentation of the PDF/UA spec itself.