[aceArtGmbH]

How about replacing HTML with Markdown?

Markdown is simpler than HTML, but has more to offer than Gemini. You could have tables, images and depending on the flavor also checkboxes. Client side styling would also be easily possible. And if you want a simple browser, you don't even have to parse it and simply show the plain text.

You do not have to be a programmer to write Markdown and many writers already write in Markdown and then convert to HTML.

[objplant]

It is possible to serve markdown files over gemini protocol (so says the specs: https://gemini.circumlunar.space/docs/specification.gmi). As for the tables, images, etc., it's up to a client (browser) to render it. For example, even though gemtext doesn't specify displaying images among text, some clients can display links to images as actual images inside the same page. Luckily, the gemtext is at least very similar to markdown, save for the link markup.

[Mediterraneo10]

Both Markdown and Gemini's markup are missing some semantic tagging useful for screenreaders. The disabled should not be second-class citizens in any new web community.

[approxim8ion]

Never thought of it this way (privileged enough to never have had to). are there any good resources that discuss this a little further?

[lolinder]

What semantic tagging does markdown miss?

[Mediterraneo10]

Take ISO-639 tagging for words in a foreign language different from the main language of the document. For example, real should be pronounced by the screenreader differently in English and Spanish, coin differently in English, French or Irish, etc. A screenreader might be able to use some heuristic to identify the language of longer snippets of text, but for one-off words it doesn’t have enough data to work with. HTML has the lang="" tag to guide screenreaders, but I am not aware of any Markdown equivalent.

[samatman]

How common is the use of these affordances in practice? I'm just now discovering that it's possible.

I'll say this: it's very cool that it's possible to make text more accessible to people using a screenreader than it is to people reading it raw. For instance, if I were to refer to the real real, I would do what I just did, and italicize the word to indicate that it's foreign. Someone who knows how Spanish works can interpolate from "italic real" and get /real/ instead of /ri:l/ out of it, and that's basically what a screenreader would do, literally say "italic real".

I'm not convinced that accessibility demands that words be pronounced properly under such circumstances. Note that someone completely ignorant of Spanish would just see "italic real" and maybe think it represents emphasis, so the sighted are not at an advantage here.

Again, it's pretty cool that there's a way to do it in HTML! Semantic markup is neat, even if it doesn't get used much.

[Mediterraneo10]

Foreign-language words used in a text are not always set in italic. For example, the author might use a proper noun (so unitalicized) like the name of a minor city in a foreign country that isn’t going to be in the screenreader's dictionary. In these cases, language tagging helps the screenreader output something intelligible instead of garbage.

Generally, use of this tagging is obligatory to meet accessibility guidelines. If in practice people don't use the tags so much, this is a problem. Again, the disabled should not be second-class citizens on the web or any medium that aims to substitute for it.

[spc476]

I don't know how common it is, but I do it. I encode foreign terms as <span lang="de" title="above everything">über alles</span>. How the client deals with that is up to the client, but most of the browsers I've used will show the title attribute if you hover over the term. I also style the <span> tags with the language attribute.