I lurk on this list, as well as the lists for collapse OS and a few other communities that I’d lump into “smol tech.” sort of an adjacent and shared space with the smol web — gemini, etc.
I wrote the following a while ago, but haven’t been certain where it made most sense to share. I published it to my blog and had some conversations about it on fedi., but I think it also may make sense for this community, too?
OG blog post, but full text also included here: https://eli.li/2022/12/14/thoughts-on-accessibility-in-smol-computing
I want to open a conversation about accessibility in this space.
I think it is an important consideration mostly left out of our community’s conversations.
I think it’s an important conversation for a variety of reasons —
Facet, ignoring it tacitly implies there isn’t space for folks who rely on assistive tech in our community, that they can’t contribute and aren’t imagined to matter in the future.
Facet, we often look back in time to older devices, implementations and implementers. For many of them the concerns of capitalism placed constraints on what they could achieve. We’re speculating about a post-capitalist ecosystem…as such, we have an opportunity to think outside of those confines. Thinking about accessibility invites us to look forward while also pulling inspiration from the past. We have constraints, they’re a different looking set than the ones on things like the apple 2, we needn’t let those constraints define our future.
Before I turn the conversation over I want to set a few core assumptions:
- accessibility is more than screen readers
- disability is something that takes a variety of forms, it is something some folks live with forever, it is something that visits some other folks briefly
- disability can compound; sometimes we need to consider more than 1 disability at a time
- disability can be visible, disability can be invisible
A first instinct may be to think of accessibility as a technical problem that needs a solution. I’d suggest that it might be an opportunity to reframe how we approach the idea itself; from accessibility to adaptability. Adaptability of methodology, problem solving, software, and devices.
thanks,
eli
On 22/12/26 03:45, Eli Mellen - hi at eli.li wrote:
>I lurk on this list, as well as the lists for collapse OS and a few other communities that I’d lump into “smol tech.” sort of an adjacent and shared space with the smol web — gemini, etc.>>I wrote the following a while ago, but haven’t been certain where it made most sense to share. I published it to my blog and had some conversations about it on fedi., but I think it also may make sense for this community, too?>>OG blog post, but full text also included here: https://eli.li/2022/12/14/thoughts-on-accessibility-in-smol-computing>>I want to open a conversation about accessibility in this space.
I agree that accessibility is paramount. If you don’t suffer from any
disability today, you are only an accident away from it.
That’s something I keep in the back of my mind when I think about
interface and one of the reason which motivates me to work on Offpunk.
I think command-line interface with linear text output are really great
for accessibility :
- you only need to type text (no complex pointer operation which are
awful)
- you only need to read text (which can be read with any device)
- you can configure the text to be exactly like you want it to be
- with a command line, you are forced to do one thing at once, which is
great for attention and many subtle mental problems
I believe that creating an interface :
- without pointer (only keyboard)
- which works well on small black/white eink screens
- which does not require any complex and hidden shortcuts
is, by essence, an interface that can easily become accessible.
That’s a least why I like so much Offpunk interface and want to extend
that paradigm to other area.
sourcehut@ploum.eu writes:
> On 22/12/26 03:45, Eli Mellen - hi at eli.li wrote:>>I lurk on this list, as well as the lists for collapse OS and a few>> other communities that I’d lump into “smol tech.” sort of an>> adjacent and shared space with the smol web — gemini, etc.>>>>I wrote the following a while ago, but haven’t been certain where it>> made most sense to share. I published it to my blog and had some>> conversations about it on fedi., but I think it also may make sense>> for this community, too?>>>>OG blog post, but full text also included here: https://eli.li/2022/12/14/thoughts-on-accessibility-in-smol-computing>>>>I want to open a conversation about accessibility in this space.>> I agree that accessibility is paramount. If you don’t suffer from any> disability today, you are only an accident away from it.>> That’s something I keep in the back of my mind when I think about> interface and one of the reason which motivates me to work on Offpunk.>> I think command-line interface with linear text output are really great> for accessibility :>> - you only need to type text (no complex pointer operation which are> awful)> - you only need to read text (which can be read with any device)> - you can configure the text to be exactly like you want it to be> - with a command line, you are forced to do one thing at once, which is> great for attention and many subtle mental problems>> I believe that creating an interface :> - without pointer (only keyboard)> - which works well on small black/white eink screens> - which does not require any complex and hidden shortcuts>> is, by essence, an interface that can easily become accessible.>> That’s a least why I like so much Offpunk interface and want to extend> that paradigm to other area.
Wouldn't you need document structure too for a practical screen reader
experience?
You might be able to visually skim a page for landmarks, but a screen
reader needs some form of structure for that.
I think taking a note from semantic HTML wouldn't hurt.
> On Dec 29, 2022, at 6:37 PM, Csepp <raingloom@riseup.net> wrote:> > > sourcehut@ploum.eu writes:> >> On 22/12/26 03:45, Eli Mellen - hi at eli.li wrote:>>> I lurk on this list, as well as the lists for collapse OS and a few>>> other communities that I’d lump into “smol tech.” sort of an>>> adjacent and shared space with the smol web — gemini, etc.>>> >>> I wrote the following a while ago, but haven’t been certain where it>>> made most sense to share. I published it to my blog and had some>>> conversations about it on fedi., but I think it also may make sense>>> for this community, too?>>> >>> OG blog post, but full text also included here: https://eli.li/2022/12/14/thoughts-on-accessibility-in-smol-computing>>> >>> I want to open a conversation about accessibility in this space.>> >> I agree that accessibility is paramount. If you don’t suffer from any>> disability today, you are only an accident away from it.>> >> That’s something I keep in the back of my mind when I think about>> interface and one of the reason which motivates me to work on Offpunk.>> >> I think command-line interface with linear text output are really great>> for accessibility :>> >> - you only need to type text (no complex pointer operation which are>> awful)>> - you only need to read text (which can be read with any device)>> - you can configure the text to be exactly like you want it to be>> - with a command line, you are forced to do one thing at once, which is>> great for attention and many subtle mental problems>> >> I believe that creating an interface :>> - without pointer (only keyboard)>> - which works well on small black/white eink screens>> - which does not require any complex and hidden shortcuts>> >> is, by essence, an interface that can easily become accessible.>> >> That’s a least why I like so much Offpunk interface and want to extend>> that paradigm to other area.> > Wouldn't you need document structure too for a practical screen reader> experience?> You might be able to visually skim a page for landmarks, but a screen> reader needs some form of structure for that.> I think taking a note from semantic HTML wouldn't hurt.
Yeah, this sort of thing is why in my initiatial message I tried to tip toe away from thinking about a specific implementation. We’ve got an opportunity to think through alternatives that are accessible/addaptable, but not necessarily what we currently have.
As a weak sauce example, what about a variable “screen” device where the output format is handled away from the implementation of the running program? The running program can be set to output to a given screen — maybe one screen renders a well known HTML format that a browser can speak and a screen reader can interpret, while another renders to something more akin to a terminal, or an immediate mode?
I agree that anything specific when it comes to software is probably
not a good way to go about a forever computer because, as a wiseman
once said, "The best way to predict the future is to invent it",
meaning if anything software-wise is done using existing paradigms,
it's already doomed to not be the 'forever computer'. Instead, it'd
be more useful to think about trends software is taking, maybe do some
brainstorming on where it's failing to connect with a person to make
them a more power-user type instead of a consumer, etc. Because if we
use what's here now, it's already on it's way to rotting and
shrivelling up to be taken over by something else. And this is a
discussion about a dream project, so instead of dreaming about the
computers out now that we've seen and don't have, why not actually
discuss real dreams, things that computers can't even do right now
that would conceptually do what the forever computer is setting out to
do (which for what it's worth, would help out THIS aspect if the
forever computer's goals are agreed upon in full...it'd be like
writing a story and all you know is you want a really cool action
scene and a lot of explosions and want it to star Chris Pine...that
says nothing about the story, the themes, the setting, etc....it helps
to think of the story and themes first and then you'd realize, maybe,
Chris Pine wouldn't be a good fit for the hero!)...
That said, every suggestion is a useful one because they can be back
referenced as the focus on the actual machine becomes clearer...we can
look back at all of this and reappraise the ideas and deem them
fitting the goal or not fitting the goal and adjusting accordingly.
:)
On Thu, Dec 29, 2022 at 8:32 PM Eli Mellen <hi@eli.li> wrote:
>>>> > On Dec 29, 2022, at 6:37 PM, Csepp <raingloom@riseup.net> wrote:> >> >> > sourcehut@ploum.eu writes:> >> >> On 22/12/26 03:45, Eli Mellen - hi at eli.li wrote:> >>> I lurk on this list, as well as the lists for collapse OS and a few> >>> other communities that I’d lump into “smol tech.” sort of an> >>> adjacent and shared space with the smol web — gemini, etc.> >>>> >>> I wrote the following a while ago, but haven’t been certain where it> >>> made most sense to share. I published it to my blog and had some> >>> conversations about it on fedi., but I think it also may make sense> >>> for this community, too?> >>>> >>> OG blog post, but full text also included here: https://eli.li/2022/12/14/thoughts-on-accessibility-in-smol-computing> >>>> >>> I want to open a conversation about accessibility in this space.> >>> >> I agree that accessibility is paramount. If you don’t suffer from any> >> disability today, you are only an accident away from it.> >>> >> That’s something I keep in the back of my mind when I think about> >> interface and one of the reason which motivates me to work on Offpunk.> >>> >> I think command-line interface with linear text output are really great> >> for accessibility :> >>> >> - you only need to type text (no complex pointer operation which are> >> awful)> >> - you only need to read text (which can be read with any device)> >> - you can configure the text to be exactly like you want it to be> >> - with a command line, you are forced to do one thing at once, which is> >> great for attention and many subtle mental problems> >>> >> I believe that creating an interface :> >> - without pointer (only keyboard)> >> - which works well on small black/white eink screens> >> - which does not require any complex and hidden shortcuts> >>> >> is, by essence, an interface that can easily become accessible.> >>> >> That’s a least why I like so much Offpunk interface and want to extend> >> that paradigm to other area.> >> > Wouldn't you need document structure too for a practical screen reader> > experience?> > You might be able to visually skim a page for landmarks, but a screen> > reader needs some form of structure for that.> > I think taking a note from semantic HTML wouldn't hurt.>> Yeah, this sort of thing is why in my initiatial message I tried to tip toe away from thinking about a specific implementation. We’ve got an opportunity to think through alternatives that are accessible/addaptable, but not necessarily what we currently have.>> As a weak sauce example, what about a variable “screen” device where the output format is handled away from the implementation of the running program? The running program can be set to output to a given screen — maybe one screen renders a well known HTML format that a browser can speak and a screen reader can interpret, while another renders to something more akin to a terminal, or an immediate mode?
I also think the solution should be text centric, as Doug McIlroy said: text …is a universal interface.
But (opinion) I think the display is kept separate from the forever-computer solution. Displays facilitate different use cases: small displays are portable, larger displays enable multi-tasking, giant displays presenting.
It makes the solution flexible and allows you to scale the experience from the simple: writing a journal in vim on a small e-ink display, to the complex: dictating zettelkasten-style notes in obsidian, on a giant screen, in a VR garden.
I guess I agree with your blog post @Eli. Fundamentally not bundling the screen gives the solution adaptability; the user can tailor the interface and display to their needs.
@sourcehut Offpunk is interesting; a calmer, slower way to consume internet content; probably consuming far fewer resources. I’d like to see some of these goals solved by forever-compute also.
Damien
> On 29 Dec 2022, at 23:37, Csepp <raingloom@riseup.net> wrote:> > > sourcehut@ploum.eu writes:> >> On 22/12/26 03:45, Eli Mellen - hi at eli.li wrote:>>> I lurk on this list, as well as the lists for collapse OS and a few>>> other communities that I’d lump into “smol tech.” sort of an>>> adjacent and shared space with the smol web — gemini, etc.>>> >>> I wrote the following a while ago, but haven’t been certain where it>>> made most sense to share. I published it to my blog and had some>>> conversations about it on fedi., but I think it also may make sense>>> for this community, too?>>> >>> OG blog post, but full text also included here: https://eli.li/2022/12/14/thoughts-on-accessibility-in-smol-computing>>> >>> I want to open a conversation about accessibility in this space.>> >> I agree that accessibility is paramount. If you don’t suffer from any>> disability today, you are only an accident away from it.>> >> That’s something I keep in the back of my mind when I think about>> interface and one of the reason which motivates me to work on Offpunk.>> >> I think command-line interface with linear text output are really great>> for accessibility :>> >> - you only need to type text (no complex pointer operation which are>> awful)>> - you only need to read text (which can be read with any device)>> - you can configure the text to be exactly like you want it to be>> - with a command line, you are forced to do one thing at once, which is>> great for attention and many subtle mental problems>> >> I believe that creating an interface :>> - without pointer (only keyboard)>> - which works well on small black/white eink screens>> - which does not require any complex and hidden shortcuts>> >> is, by essence, an interface that can easily become accessible.>> >> That’s a least why I like so much Offpunk interface and want to extend>> that paradigm to other area.> > Wouldn't you need document structure too for a practical screen reader> experience?> You might be able to visually skim a page for landmarks, but a screen> reader needs some form of structure for that.> I think taking a note from semantic HTML wouldn't hurt.>
"But (opinion) I think the display is kept separate from the
forever-computer solution. Displays facilitate different use cases:
small displays are portable, larger displays enable multi-tasking,
giant displays presenting."
I agree with this. I think the greatest common denominator of a
forever computer would be something like a mini-motherboard, with a
standardized display connector/adapter that can support plug and play
e-ink displays. Model A of the Quartz64 currently uses an FPC
connector for e-ink (which I confirmed from contacting their Discord
channel), but it also supports e-displayport, which also supports
lower refresh rates. https://www.pine64.org/quartz64a/https://wiki.pine64.org/wiki/Quartz64 I find it somewhat funny that
the display market has only two refresh rates: fast and faster. Henry
Ford supposedly once said, in his own "co-written" autobiography (an
oxymoron if I knew one):
"Instead, it appears in Henry Ford’s co-written autobiography, “My
Life and Work,” published in 1922. He describes a meeting in 1909 with
his company’s salespeople, who wanted him to add even more models.
Instead, he announced he would build only one, “and I remarked: ‘Any
customer can have a car painted any color that he wants so long as it
is black.’” https://collectorsautosupply.com/blog/true-or-false-did-ford-really-say-any-color-the-customer-wants-as-long-as-its-black/
Today, mass-market refresh rates are typically offered in two volumes:
loud and louder
https://memes.getyarn.io/yarn-clip/4137a8e3-3a3b-4f5a-ba18-89f86ddadcca
60fps is usually the minimum, and phones today have 90 and even
120fps.
Adaptive sync is really a nice solution for higher refresh rate issues
above 24Hz, but the technology was designed to serve a lucrative
gaming market. Of course, issues like screen tearing and stuttering
are caused by high bandwidth, and a different phenomena likely occurs
with different substrates such as electrophoretic displays, but the
overall issue of ghosting/residual text, which does not correspond to
the intended and current content, can affect all displays in one way
or another. Thus, a display interface which can be scalable for lower
frame buffers would work best with a variable, programmable and
adaptive refresh controller, using a single display interface, most
likely i2C https://en.wikipedia.org/wiki/I%C2%B2C, or SPI (serial
peripheral interface). Rather than have multiple, incompatible FPC
ports with different sizes and pin numbers, a standard FPC for
low-power and low-refresh displays could support screens as small as
1x1 pixel and 27" monitors. But I am not sure if a one-size fits all
would make economic sense for smaller PCBs, especially if the FPC is
larger than the use-case (i.e a tiny wildlife GPS beacon monitoring
rainforest humidity perched on a branch for forest rangers to check
why a beacon may be unable to transmit data, as local data/battery
life can be checked even with a passersby's phone camera instead of
using NFC or some USB interface which may not be available).
That's a specific use case, where redundant, overengineered components
may not be added to a PCB (esp if not easily waterproof). But I see
few reasons why a standard display connector can't be developed in a
plug and play method for smaller displays, as the motherboard and
processor would likely support a very flexible number of display
resolutions.
On Sat, Dec 31, 2022 at 4:51 AM Damien Slater <damien@slater.email> wrote:
>> I also think the solution should be text centric, as Doug McIlroy said: text …is a universal interface.>> But (opinion) I think the display is kept separate from the forever-computer solution. Displays facilitate different use cases: small displays are portable, larger displays enable multi-tasking, giant displays presenting.>> It makes the solution flexible and allows you to scale the experience from the simple: writing a journal in vim on a small e-ink display, to the complex: dictating zettelkasten-style notes in obsidian, on a giant screen, in a VR garden.>> I guess I agree with your blog post @Eli. Fundamentally not bundling the screen gives the solution adaptability; the user can tailor the interface and display to their needs.>> @sourcehut Offpunk is interesting; a calmer, slower way to consume internet content; probably consuming far fewer resources. I’d like to see some of these goals solved by forever-compute also.>> Damien>> > On 29 Dec 2022, at 23:37, Csepp <raingloom@riseup.net> wrote:> >> >> > sourcehut@ploum.eu writes:> >> >> On 22/12/26 03:45, Eli Mellen - hi at eli.li wrote:> >>> I lurk on this list, as well as the lists for collapse OS and a few> >>> other communities that I’d lump into “smol tech.” sort of an> >>> adjacent and shared space with the smol web — gemini, etc.> >>>> >>> I wrote the following a while ago, but haven’t been certain where it> >>> made most sense to share. I published it to my blog and had some> >>> conversations about it on fedi., but I think it also may make sense> >>> for this community, too?> >>>> >>> OG blog post, but full text also included here: https://eli.li/2022/12/14/thoughts-on-accessibility-in-smol-computing> >>>> >>> I want to open a conversation about accessibility in this space.> >>> >> I agree that accessibility is paramount. If you don’t suffer from any> >> disability today, you are only an accident away from it.> >>> >> That’s something I keep in the back of my mind when I think about> >> interface and one of the reason which motivates me to work on Offpunk.> >>> >> I think command-line interface with linear text output are really great> >> for accessibility :> >>> >> - you only need to type text (no complex pointer operation which are> >> awful)> >> - you only need to read text (which can be read with any device)> >> - you can configure the text to be exactly like you want it to be> >> - with a command line, you are forced to do one thing at once, which is> >> great for attention and many subtle mental problems> >>> >> I believe that creating an interface :> >> - without pointer (only keyboard)> >> - which works well on small black/white eink screens> >> - which does not require any complex and hidden shortcuts> >>> >> is, by essence, an interface that can easily become accessible.> >>> >> That’s a least why I like so much Offpunk interface and want to extend> >> that paradigm to other area.> >> > Wouldn't you need document structure too for a practical screen reader> > experience?> > You might be able to visually skim a page for landmarks, but a screen> > reader needs some form of structure for that.> > I think taking a note from semantic HTML wouldn't hurt.> >>
--
Giovanni Lostumbo
708-303-8175
FPC display port. I like it and it could be adapted to future displays over FPC.
@Giovanni I wouldn’t worry about supporting all displays and sizes. Someone connecting a screen using a ribbon cable, probably won’t be disconnecting it again frequently and the screen sizes you mentioned cover everything from a watch to beyond laptop; giving you > 80% of today’s use-cases.
Just to add, with either BT PAN or a WiFi hotspot you can talk with any piece of glass you have in your bag today as well as any display with a browser beyond 27inch. Its not an unreasonable bet, both will be around in 50 years given how long both have been around so far.
Damien
> On 31 Dec 2022, at 17:28, Giovanni Lostumbo <giovanni.lostumbo@gmail.com> wrote:> > "But (opinion) I think the display is kept separate from the> forever-computer solution. Displays facilitate different use cases:> small displays are portable, larger displays enable multi-tasking,> giant displays presenting."> > I agree with this. I think the greatest common denominator of a> forever computer would be something like a mini-motherboard, with a> standardized display connector/adapter that can support plug and play> e-ink displays. Model A of the Quartz64 currently uses an FPC> connector for e-ink (which I confirmed from contacting their Discord> channel), but it also supports e-displayport, which also supports> lower refresh rates. https://www.pine64.org/quartz64a/> https://wiki.pine64.org/wiki/Quartz64 I find it somewhat funny that> the display market has only two refresh rates: fast and faster. Henry> Ford supposedly once said, in his own "co-written" autobiography (an> oxymoron if I knew one):> > "Instead, it appears in Henry Ford’s co-written autobiography, “My> Life and Work,” published in 1922. He describes a meeting in 1909 with> his company’s salespeople, who wanted him to add even more models.> Instead, he announced he would build only one, “and I remarked: ‘Any> customer can have a car painted any color that he wants so long as it> is black.’” https://collectorsautosupply.com/blog/true-or-false-did-ford-really-say-any-color-the-customer-wants-as-long-as-its-black/> > Today, mass-market refresh rates are typically offered in two volumes:> loud and louder> https://memes.getyarn.io/yarn-clip/4137a8e3-3a3b-4f5a-ba18-89f86ddadcca> 60fps is usually the minimum, and phones today have 90 and even> 120fps.> > Adaptive sync is really a nice solution for higher refresh rate issues> above 24Hz, but the technology was designed to serve a lucrative> gaming market. Of course, issues like screen tearing and stuttering> are caused by high bandwidth, and a different phenomena likely occurs> with different substrates such as electrophoretic displays, but the> overall issue of ghosting/residual text, which does not correspond to> the intended and current content, can affect all displays in one way> or another. Thus, a display interface which can be scalable for lower> frame buffers would work best with a variable, programmable and> adaptive refresh controller, using a single display interface, most> likely i2C https://en.wikipedia.org/wiki/I%C2%B2C, or SPI (serial> peripheral interface). Rather than have multiple, incompatible FPC> ports with different sizes and pin numbers, a standard FPC for> low-power and low-refresh displays could support screens as small as> 1x1 pixel and 27" monitors. But I am not sure if a one-size fits all> would make economic sense for smaller PCBs, especially if the FPC is> larger than the use-case (i.e a tiny wildlife GPS beacon monitoring> rainforest humidity perched on a branch for forest rangers to check> why a beacon may be unable to transmit data, as local data/battery> life can be checked even with a passersby's phone camera instead of> using NFC or some USB interface which may not be available).> > That's a specific use case, where redundant, overengineered components> may not be added to a PCB (esp if not easily waterproof). But I see> few reasons why a standard display connector can't be developed in a> plug and play method for smaller displays, as the motherboard and> processor would likely support a very flexible number of display> resolutions.> > On Sat, Dec 31, 2022 at 4:51 AM Damien Slater <damien@slater.email> wrote:>> >> I also think the solution should be text centric, as Doug McIlroy said: text …is a universal interface.>> >> But (opinion) I think the display is kept separate from the forever-computer solution. Displays facilitate different use cases: small displays are portable, larger displays enable multi-tasking, giant displays presenting.>> >> It makes the solution flexible and allows you to scale the experience from the simple: writing a journal in vim on a small e-ink display, to the complex: dictating zettelkasten-style notes in obsidian, on a giant screen, in a VR garden.>> >> I guess I agree with your blog post @Eli. Fundamentally not bundling the screen gives the solution adaptability; the user can tailor the interface and display to their needs.>> >> @sourcehut Offpunk is interesting; a calmer, slower way to consume internet content; probably consuming far fewer resources. I’d like to see some of these goals solved by forever-compute also.>> >> Damien>> >>> On 29 Dec 2022, at 23:37, Csepp <raingloom@riseup.net> wrote:>>> >>> >>> sourcehut@ploum.eu writes:>>> >>>> On 22/12/26 03:45, Eli Mellen - hi at eli.li wrote:>>>>> I lurk on this list, as well as the lists for collapse OS and a few>>>>> other communities that I’d lump into “smol tech.” sort of an>>>>> adjacent and shared space with the smol web — gemini, etc.>>>>> >>>>> I wrote the following a while ago, but haven’t been certain where it>>>>> made most sense to share. I published it to my blog and had some>>>>> conversations about it on fedi., but I think it also may make sense>>>>> for this community, too?>>>>> >>>>> OG blog post, but full text also included here: https://eli.li/2022/12/14/thoughts-on-accessibility-in-smol-computing>>>>> >>>>> I want to open a conversation about accessibility in this space.>>>> >>>> I agree that accessibility is paramount. If you don’t suffer from any>>>> disability today, you are only an accident away from it.>>>> >>>> That’s something I keep in the back of my mind when I think about>>>> interface and one of the reason which motivates me to work on Offpunk.>>>> >>>> I think command-line interface with linear text output are really great>>>> for accessibility :>>>> >>>> - you only need to type text (no complex pointer operation which are>>>> awful)>>>> - you only need to read text (which can be read with any device)>>>> - you can configure the text to be exactly like you want it to be>>>> - with a command line, you are forced to do one thing at once, which is>>>> great for attention and many subtle mental problems>>>> >>>> I believe that creating an interface :>>>> - without pointer (only keyboard)>>>> - which works well on small black/white eink screens>>>> - which does not require any complex and hidden shortcuts>>>> >>>> is, by essence, an interface that can easily become accessible.>>>> >>>> That’s a least why I like so much Offpunk interface and want to extend>>>> that paradigm to other area.>>> >>> Wouldn't you need document structure too for a practical screen reader>>> experience?>>> You might be able to visually skim a page for landmarks, but a screen>>> reader needs some form of structure for that.>>> I think taking a note from semantic HTML wouldn't hurt.>>> >> > > > -- > Giovanni Lostumbo> 708-303-8175>