> Edbrowse is a combination editor, browser, and mail client that is 100% text based... The inspiration for this program came from Karl's many years of experience as a blind computer user.
> You can edit a URL as easily as a local file, and activate browse mode to...discard most of the formatting information and retain the links and fill-out forms. This allows blind users to access the Internet through an application that is compatible with the linear nature of speech or braille.
> The interface is similar to /bin/ed, though there are many more features, such as editing multiple files simultaneously, and rendering html.
> This program was originally written for blind users, but many sighted users have taken advantage of the unique scripting capabilities of this program, which can be found nowhere else. A batch job, or cron job, can access web pages on the internet, submit forms, and send email, with no human intervention whatsoever.
Yup; I'm a sighted user who uses edbrowse daily. I don't understand why TUI browsers like w3m, lynx, and links2 went mainstream instead of line-mode browsers like edbrowse.
I actually test my sites on edbrowse and w3m before I test in other graphical browsers like Konqueror (Blink and KHTML), Epiphany (Webkit), and Firefox because the latter group is nearly guaranteed to work if the former does too.
If every simple progressively-enhanced non-app website supported edbrowse and NetSurf, maybe the Web wouldn't have ended up becoming this mess.
Thanks for posting this. I've actually seen it many years ago but never tried it. I'm not blind but I'm actually interesting in making UIs for blind people and the CLI seems to look perfect for this. Can you confirm that?
BTW, do you know if TUI programs (using curses/ncurses or related) are usable for blind users?
Pure clis (where you type commands and get answers) are okay. Ncurses apps are sorta kinda usable, but a native GUI is way better. With a real web browser or native GUI, a screen reader has access to semantic information, so it can tell you that you've reached a table with 3 rows and 5 columns. It can then let you navigate that table by row, by column, by a mix of both, or in whatever way you choose. With a terminal UI, all you have is dashes and vertical bars, which will be [read as dashes and vertical bars. You can make sense of them, given enough time and patience, but GUIs are just way easier.
The guideline I give for accessibility of textual interfaces is "make it look good in a non-monospaced font, with no color support". Don't expect character 33 in line 12 to be directly under character 33 in line 11. If nothing breaks, you're probably good to go.
Edit: just realized that you were talking about software in general, and not (web) documents. This comment assumed you were talking about webpages. That being said: this comment might be useful to someone else, so I don't have the heart to delete it.
Original comment:
Supporting terminal-based and line-mode browsers doesn't prevent you from supporting graphical browsers with screenreader support; on the contrary, it can actually help improve cross-browser compatibility by encouraging authors to use simpler progressively-enhanced technologies.
Using a textual browser encourages authors to focus on text, and to think twice about non-textual content. Tables and images have their place, but should be used judiciously when ordinary text simply won't convey an idea well. The result is an even more accessible page for everyone, whether they're using a braille reader, dictation, "reader mode", a printout, or a hacky webpage-to-markdown-to-epub shell script.
Supporting 100 edge cases with under four users each is too much to ask, but supporting plain-text browsers automatically covers a wide variety of such edge cases with no additional effort.
I use Edbrowse all the time, including to read Hacker News. You can add custom functions into ~/.ebrc, and I have one to search for the next post on an HN page, or the "More" link, if there are no more posts on the current page.
function:hnn {
/^\({} \|{More}\)
}
Edbrowse supports JavaScript, but it doesn't work very well, so I turn it off at startup, and only turn it on if I think it might make a page work better (it usually doesn't). Here's a bit of my config:
# I use certifi to provide the trusted root certificate authorities
certfile=/usr/local/lib/python3.8/site-packages/certifi/cacert.pem
jar=/Users/ncarpenter/.config/edbrowse/cookiejar
downdir = /Users/ncarpenter/Downloads
# Disable cache, so each Edbrowse session doesn't cache where I've been to disk.
# It doesn't have persistent history anyways.
cachesize=0
# User agents (type ua0 for edbrowse, ua1 for Lynx, etc)
agent = Lynx/2.8.4rel.1 libwww-FM/2.14
agent = Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)
agent = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3112.113 Safari/537.36
# Automatically convert Markdown, Epub, PDF to HTML
plugin {
type = markdown
desc = markdown file
suffix = md
program = pandoc --toc -f markdown %i
outtype = H
down_url
}
plugin {
type = epub
desc = epub file
suffix = epub
content = application/epub+zip
# %o is the temp output file generated by the program
program = pandoc -f epub %i
outtype = H
down_url
}
plugin {
type = pdf
desc = pdf file
suffix = pdf
content = application/pdf
# file must be local
down_url
program = pdftohtml -i -noframes %i %o >/dev/null
outtype = H
}
# Play links to audio with mpv
plugin {
type = audio
desc = streaming audio
protocol = rtsp,pnm,sdp,pls
suffix = rm,ra,ram,ogg,mp3,mp4,m3u,m3u8,opus,flac
content = audio/x-scpls,audio/mpeg,application/pls+xml
program = mpv --really-quiet --no-audio-display --no-ytdl --af=scaletempo=stride=20:overlap=1 %i
}
# Use mps-youtube to handle Youtube URLs
plugin {
type = audio/youtube
desc = streaming audio from Youtube
suffix=mpeg # Doesn't matter, but needed for edbrowse not to complain
urlmatch = .youtube.com/watch?
program = mpsyt url %i
}
# These commands run when Edbrowse starts
# See the user's guide for what these commands mean, but I'm basically setting up startup preferences
function:init {
db0
js-
sg+
ci+
dx
endm+
rl+
z37
db1
}
function:b {
b ~/.config/edbrowse/bookmarks
}
function+atb {
db0
A
,j
w+ ~/.config/edbrowse/bookmarks
^
db1
}
# Typing <hs some.domain.tld is easier than typing
# b https://some.domain.tld
function:hs {
b https://~0
}
# Because I read RFCs enough to make use of this
function+rfc {
b https://tools.ietf.org/html/rfc~1
}
# Open the current page in the default browser,
# when it just isn't working right in Edbrowse.
function+o {
db0
ub
!open "'_"
b
db1
}
...
I just wrote a plugin to make Edbrowse work with gemini. It supports TOFU, prompts, client certificates, handles redirects, and passes most of the gemini torture tests, that don't involve crazy unicode wrapping.
Edbrowse's plugin support is extremely basic, so telling it about other media types, and auto redirecting away from gemini isn't possible without modifications to Edbrowse, as far as I know. I plan to add a few more features, like the ability to view the server certificate, and move up a directory, but I've only put about six or so hours into this thing so far, having never even used a gemini client beforehand.
Here's the plugin portion that goes into your Edbrowse configuration (~/.ebrc; you'll need to update the paths for your local system). If you want to use a client certificate, add -c your-cafile.crt -C your-cakey.crt to the program = ... line, before %i.
plugin {
type = */*
desc = Gemini
protocol = gemini
program = /Users/ncarpenter/.config/edbrowse/plugins/ebgmni.py %i
outtype = h
}
And here's the helper Python script. It's a simple gemini client that converts text/gemini responses to HTML, for display in Edbrowse. You'll need to pip install ignition-gemini. The above plugin's program = line should point to it.
11 comments
[ 4.5 ms ] story [ 35.4 ms ] thread> Edbrowse is a combination editor, browser, and mail client that is 100% text based... The inspiration for this program came from Karl's many years of experience as a blind computer user.
> You can edit a URL as easily as a local file, and activate browse mode to...discard most of the formatting information and retain the links and fill-out forms. This allows blind users to access the Internet through an application that is compatible with the linear nature of speech or braille.
> The interface is similar to /bin/ed, though there are many more features, such as editing multiple files simultaneously, and rendering html.
> This program was originally written for blind users, but many sighted users have taken advantage of the unique scripting capabilities of this program, which can be found nowhere else. A batch job, or cron job, can access web pages on the internet, submit forms, and send email, with no human intervention whatsoever.
I actually test my sites on edbrowse and w3m before I test in other graphical browsers like Konqueror (Blink and KHTML), Epiphany (Webkit), and Firefox because the latter group is nearly guaranteed to work if the former does too.
If every simple progressively-enhanced non-app website supported edbrowse and NetSurf, maybe the Web wouldn't have ended up becoming this mess.
BTW, do you know if TUI programs (using curses/ncurses or related) are usable for blind users?
Pure clis (where you type commands and get answers) are okay. Ncurses apps are sorta kinda usable, but a native GUI is way better. With a real web browser or native GUI, a screen reader has access to semantic information, so it can tell you that you've reached a table with 3 rows and 5 columns. It can then let you navigate that table by row, by column, by a mix of both, or in whatever way you choose. With a terminal UI, all you have is dashes and vertical bars, which will be [read as dashes and vertical bars. You can make sense of them, given enough time and patience, but GUIs are just way easier.
The guideline I give for accessibility of textual interfaces is "make it look good in a non-monospaced font, with no color support". Don't expect character 33 in line 12 to be directly under character 33 in line 11. If nothing breaks, you're probably good to go.
Original comment:
Supporting terminal-based and line-mode browsers doesn't prevent you from supporting graphical browsers with screenreader support; on the contrary, it can actually help improve cross-browser compatibility by encouraging authors to use simpler progressively-enhanced technologies.
Using a textual browser encourages authors to focus on text, and to think twice about non-textual content. Tables and images have their place, but should be used judiciously when ordinary text simply won't convey an idea well. The result is an even more accessible page for everyone, whether they're using a braille reader, dictation, "reader mode", a printout, or a hacky webpage-to-markdown-to-epub shell script.
Supporting 100 edge cases with under four users each is too much to ask, but supporting plain-text browsers automatically covers a wide variety of such edge cases with no additional effort.
[1]: https://en.wikipedia.org/wiki/Lynx_(web_browser)
Here's the plugin portion that goes into your Edbrowse configuration (~/.ebrc; you'll need to update the paths for your local system). If you want to use a client certificate, add -c your-cafile.crt -C your-cakey.crt to the program = ... line, before %i.
And here's the helper Python script. It's a simple gemini client that converts text/gemini responses to HTML, for display in Edbrowse. You'll need to pip install ignition-gemini. The above plugin's program = line should point to it.https://gist.github.com/n0ot/b257e44a414732ef97ca08c00b5a7a9...