A proposed scheme for parsing preformatted alt text

[A. E. Spencer-Reed]

When parsing closing lines with extra text after the "```", should
they just be treated as part of the block? ex. should
```Alt Text
1
```2
3
```
4

look like
+------------------------------+
| 1                            |
| ```2                         |
| 3                            |
+------------------------------+
4

or

+------------------------------+
| 1                            |
+------------------------------+
3
+------------------------------+
| 4                            |
+------------------------------+


On Thu, Sep 10, 2020 at 1:54 PM James Tomasino <tomasino at lavabit.com> wrote:
>
> On 9/10/20 5:47 PM, mbays at sdf.org wrote:
> > How about if clients have an easily toggled switch between showing
> > preformatted text and just showing alt text? I guess that would still
> > lead to more easter-egging, but maybe not too much? It seems there's a
> > tradeoff between discouraging inaccessible uses as human-readable text,
> > and discouraging inaccessible uses as machine-readable text...
>
> I've been thinking about clients toggling the visibility of preformatted text. While it may not provide much value in a desktop client for sighted users, this could be very useful in mobile clients. Preformatted text is one of the troublesome areas that screws up displays on narrow screens. If a mobile client were to serve the alternate text instead then visitors could choose whether they want to expand it to see the preformatted content.
>
> This sort of flow is exactly what a screen reader would be doing for a blind user. It serves up that alternate text first and the user then can decide whether it is worth the effort to dive into the contents further.
>
> Maybe it will also help keep alt-text top-of-mind for content authors if they run into it themselves in the proper context.
>


-- 
🍵