💾 Archived View for tilde.team › ~tomasino › journal › 20200601-accessibility.gmi captured on 2021-12-03 at 14:04:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
There has been discussion about the text/gemini format again on the mailing list centered around the accessibility of preformatted blocks (```). There were a number of great observations and suggestions made. I will attempt to summarize here in the hopes that we can find some general consensus and begin an official accessibility block within the spec-spec.
Gemini is designed so that text in paragraphs like this one or in headings and list items can all be treated with variable line widths and font treatments. This is designed to improve readability across devices and to individual tastes. Some content, however, was not appropriate for these types of reflow:
To support these efforts a pre-formatted block can be defined by using a "fence" of three backtick characters (```) at the start of the line before and after the block. For example:
```
this line is preformatted
and
will
preserve
white space
```
While these options give great flexibility for users composing content, it has drawbacks for two types of content consumers:
Search engines may have difficulty in indexing content on gemini if that content contains ASCII art or other non-text content. This can lower the quality of indexing and search overall.
Individuals trying to consume gemini content using assistive devices like screen readers also face a challenge in understanding or navigating through pre-formatted blocks that may not be written in parseable text. For instance, a page heading styled with figlet would seem like nonsense, but also, a long code block may be a barrier to content further down the page.
A manner of navigating and understanding the semantics of these blocks would be helpful to both groups.
One early and popular suggestion for these pre-formatted blocks is to use the opening backtick fence to indicate the content within the block in the style of HTML images' alt text.
This solution puts minimal burden on content authors and would fail gracefully for content that is being ported from gopher or other systems with preformatted lines. It is focused exclusively on providing an accessible experience for users that need it and promoting better searchability.
In contrast to solution 1, adding additional formatting rules to the alt-text content following a backtick fence would allow for additional parsing information. Most notably, it could be used to indicate that the block contains source-code and the language, allowing for clients to easily implement syntax highlighting for sighted users.
An example of this format might be something like:
Alternatively the types could be optional and indicated with a special character. Failure to use that character could indicate it is a simple alt-text. For example:
Various formatting ideas were presented for this content with most focusing on some sort of type identifier to start the text followed by optional additional information.
Solderpunk has stated his intention to embrace accessibility within gemini. The goals of the project favor simple solutions with little complexity. The proposed alt-text solution fits the goal and means well.
The addition of types or other metadata into the alt text adds some small amount of complexity in exchange for valuable information about the structure of a certain type of content.
Some clients are already beginning to add some manner of support for alt-text. Others have begin experimenting with using preformatted block fences as a rudimentary commenting system since the lines themselves are to be omitted from rendering in visual clients. I propose we try to find a quick consensus so that all our efforts can be aimed in the right direction.
Originally Published 2020-06-01 at:
gemini://tilde.team/~tomasino/journal/20200601-accessibility.gmi
If you have questions or thoughts to add please send me a link to your response.