Incorrect. It is actually bad for accessibility.
Because gemtext was so deliberately hobbled in functionality, it is actively hostile to users with accessibility needs.
No tables means people have to do things with ASCII art which makes them incomprehensible to screen readers.
Standalone images (i.e. not online with the content) means you cannot provide any textual clues or context to what the image is about - you just get the image on its own. And the pervasive use of ASCII art "images" obviously is terrible.
No way to specify descriptive labels for links.
No way to visually-hide content so that it is only visible to screen readers.
No way to use aria-style tags to semantically mark up the different sections of a page (this is the navigation are, this is the gemlog listing etc)
A bit web-centric but I think important considering the ASCII table issue, no way to use JavaScript to provide what is known as "managed focus" handlers to allow navigation of cells/content areas using cursors+space+enter etc.
I can't remember, but I don't know if it even has in-page anchors?
They should have made gemtext slightly more sophisticated - inline images, proper tables, and basic visual styling would solve a lot of the a11y issues.
It is a shame. I got into Gemini a bit a while ago (even wrote a basic library for deno @ https://github.com/matt1/deno-gemini (essentially a fork of my own https://github.com/matt1/deno-gopher) and started work on a GUI client). I started to experiment with a totally-non-spec "style" spec that my client would support - essentially a line-by-line thing similar to CSS to apply the most basic of styles (colour, font weight, size etc) to gemtext lines, and which would be loaded from a well-known file (similar to robots.txt etc - compatible clients would load styles.gem or whatever).
But ultimately I was scared off by the short-comings of gemtext, and the staunch refusal to consider any changes or improvements. Which is fine, it is their spec and they don't have to change anything, but its why I left.