Gemtext Is Not Accessible
By Artyom BologovGemini and Gemtext are powerful ideas. If not as the actual implementation/praxis, then at least as a source of inspiration. How cool could it be to have a markup/hypertext language that doesn't allow any inline decorations? Only blocks and lines. The thought flows unhindered through the paragraphs and quotes. Minimalist writing. By design.
But Gemtext minimalism is both a blessing and a curse. And the curse is that it's actually inaccessible. Many pages (including mine) break the advertized accessibility by using the elements in the wrong way. And the language/markup itself doesn't make it easier.
Disclaimer: I'm not as much pointing out flaws in Gemtext (although the accessibility situation is sympthomatic of systemic flaws in it) as showing that the current practice of Gemtext use is inaccessible. It's the actual use of markup language that's broken, no matter what the core language claims.
Preformatted Blocks and Alt Text
The biggest thing that's broken about Gemtext is preformatted text blocks. And I am not the first person to notice that. Protocol spec lists screen reader accessibility as use-case for block alt text. But there's no way to guess what one would write in there. And the current frequent practice is either
- Leaving alt text blank.
- Or putting programming language tag (akin to Github-Flavored Markdown ones) there.
Neither of these helps the screen reader to guess whether to read the block or not. Which means it is not accessible at all. We're back to the age of HTML1 here. Especially with the omnipresent ASCII art used for page decoration. At least it's not GIFs, I guess?
There are multiple ways to change the status quo:
- Suggest to always make alt text a language/content code, like "javascript" or "ascii art".
- Add more structure to alt text, like (unofficial yet ubiquitous)
lang=javascriptand<figcaption>in HTML. - Clarify in which way the alt text is intended to be processed by screen readers.
- Or even introduce a separate "caption" line/block to attach to preformatted blocks.
Notice that all of these are suggestion for the spec, and not for the users. I'm not sure what to recommend to users. Caption your preformatted blocks? At least with something?
Lists Abuse
Lists are probably the second most decorative and misused type of lines after preformatted ones. They are (mis)used to
- Indent the content.
- Add "captions" to pre-s and quotes (see the index.gmi page on my blog for an example.)
- Or to make heading-like paragraph breaks (see project.gmi)
All of these go beyond what lists semantically are. Yet all of these are present in many Gemtext documents. We need to do better.
One solution that could work is the one already suggested above: Add a "caption" line to cover the list-after-blockquote use-case. Other use-cases are not really fixable: Indentation is a matter of writer wanting a weird display and going against Gemini philosopy ("styling is on user"); And heading-like use will benefit from real headings instead.
Paragraphs as Auxiliary Information
Paragraphs are often used to expand on the lines preceding them. As longer explanation for list bullet points, for example. I'm misusing them this way, at least.
Having caption/aux line could fix that too?
Is That It?
These are the biggest pieces of Gemtext praxis that I've seen that are inaccessible. And semantically broken too. Not that many breakages, but all too frequent on real pages.
The definitive suggestion that could cover most of these cases is adding one more line.
"Aux" or "caption" line.
Basically what <figcaption> does to HTML5.
Something like:
> A blockquote
? Author of the quote, year XXXX
But I realize that Gemtext is not really changeable at this point. So we're stuck with inaccessible and semantically broken content?