1. 27
  1.  

  2. 3

    The web browser will do all of these things for you — trust it to do a good job.

    More like I don’t trust myself to be even close to as good.

    1. 5

      curl https://sourcehut.org/blog/2020-05-27-accessibility-through-simplicity/ | tr '\n' ' ' | sed 's/<[^>]*>//g; s/&nbsp;//g; s/&..quot;/"/g; s/&lt;/</g; s/&gt;/>/g; s/ */ /g' | xargs -0 espeak -w 2020-05-27-accessibility-through-simplicity.wav

      http://josuah.net/tmp/2020-05-27-accessibility-through-simplicity.wav

      1. 12

        I get that you’re demonstrating how a simple page enables simple tools for reading it.

        But, to avoid any misconceptions, it’s been many years since blind people have used specialized browsers, built from the ground up for blind people, to read web pages. We mostly use mainstream browsers together with screen readers now. And even the old specialized browsers were more advanced than the Unix pipeline you gave; they properly parsed HTML and let the user move around the page and interactively read parts of it.

        And your pipeline has some problems even for a simple page like this one. Notice that the &rsquo; entities were unhandled.

        1. 2
          • Half-assed implementation
          • Does not support scrolling around,
          • Does not “properly parse HTML”
          • Bug with &rsquo; (assumed &rsquot;)
          • Low quality voice
          • Supports a hardcoded URL
          • Uses tr and xargs because the author cannot read the manpage of espeak properly
          • Does not understand semantics elements like <em>, <code>, <li>, …
          • Uses expensive .wav output

          Hmm… we’ll see again about using that pipeline for anything beyond a flawed proof of concept.

          old specialized browsers

          Is edbrowse one of them?