85 lines
4.7 KiB
Plaintext
85 lines
4.7 KiB
Plaintext
# Accessibility in text/gemini
|
|
|
|
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.
|
|
|
|
## The environment
|
|
|
|
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:
|
|
|
|
* code samples
|
|
* some forms of poetry with meaningful white space
|
|
* ASCII art
|
|
|
|
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:
|
|
|
|
``` code example
|
|
```
|
|
this line is preformatted
|
|
and
|
|
will
|
|
preserve
|
|
white space
|
|
```
|
|
```
|
|
|
|
## The problem
|
|
|
|
While these options give great flexibility for users composing content, it has drawbacks for two types of content consumers:
|
|
|
|
* search engines
|
|
* individuals using screen readers
|
|
|
|
### Search Engines
|
|
|
|
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.
|
|
|
|
### Screen Readers
|
|
|
|
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.
|
|
|
|
## Possible solutions
|
|
### alt text
|
|
|
|
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.
|
|
|
|
* The text would be a free-form text area following the ```[single space] pattern
|
|
* The alt-text would be read to screen readers before beginning the block
|
|
* If the assistive device is interactive, it could prompt the user if they want to read the contents of the block or skip it
|
|
* search engines would index the alt content INSTEAD of the block
|
|
* if no alt-text is present, the block can be assumed to be indexable and readable
|
|
|
|
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.
|
|
|
|
### alt text with metadata
|
|
|
|
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:
|
|
|
|
* ``` code:javascript
|
|
* ``` image:a picture of the moon
|
|
|
|
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:
|
|
|
|
* ``` !code:javascript
|
|
* ``` a picture of the moon
|
|
|
|
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.
|
|
|
|
## Conclusion
|
|
|
|
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.
|
|
=> /~tomasino/about.txt Contact Information
|