Re: Org mode export accessibility

[briangpowell <briangpowellms@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5452 bytes --]

"[I suspect that the exported documents can similarly be improved to
reduce the amount of effort required from visually impaired users to read
such documents. The question is what improvements can be made on
Org side.]

Best,
Ihor"

Very glad to hear from TV Raman, the creator of EmacSpeak,

I'm not blind like TV but I was motivated to turn my a main OrgMode buffer
into an audio desktop like TV's

But now back to the topic; much agree with Ihor, we should focus on "what
improvements can be made on OrgMode side"

& TV's points are well made too: "pdftex and pdflatex were built in the
late 90's"--very true & they were rarely useful

Suggest OrgMode make changes aimed at the "Lowest Common Denominator" of
accessibility--accessibility in the visual sense AND in the machine or
program processable sense or more exactly the "document convertible
sense"--I mean documents should be made firstly in a form that all
computers can easily navigate & present on computer screens and/or audio
desktops in addition to being readily able to print out

TV's right, the usual pipeline of LaTeX->PDF can produce tagged & useful
documents but can an end user easily copy and paste the document? How
useful are pretty documents that run on proprietary systems? Many PDF's can
make simple processes like this very hard or impossible--the documents can
be very pretty but they can contain control characters & special characters
& even malicious code

Suggest OrgMode outputs focus on creating "Lowest Common Denominator"
documents as output:
TeXinfo docs should be used as the LCD doctype--suggest you focus on
creating 1 document in Texinfo that you use to create all other sorts of
documents, when possible:

Pipeline should be more like
OrgMode->Texinfo->TROFF||DTD/XML/HTML/XHTML->LaTeX/TeX->DVI||SVG->PS->PDF

* TeXinfo: https://savannah.gnu.org/projects/texinfo
https://www.gnu.org/software/texinfo

** "Texinfo uses a single source file to produce output in a number of
formats, both online and printed (dvi, html, info, pdf, xml, etc.). This
means that instead of writing different documents for online information
and another for a printed manual, you need write only one document.  And
when the work is revised, you need revise only that one document.  The
Texinfo system is integrated well with GNU Emacs.

*** Texinfo docs can also be viewed & used by ALL end-users without any
issues--regardless of the power of their computer or monitor or even if
they're blind like TV Raman--he uses an audio desktop or EmacSpeak--and the
same docs can be printed on any printer & remain navigable with "rn" &
other simple news-reading software--or the "info" program

* Output formats currently supported by Texinfo:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Output-Formats.html
<=> Info,Text,HTML,DVI,PostScript{PS},PDF,DocBook,XML

** Related/useful may be: "latex2nemeth"--a LATEX to Braille/Nemeth,
approach "Simple pictures in PSTricks are also supported in order to
produce tactile graphics": https://ctan.org/pkg/latex2nemeth

On Thu, Jun 30, 2022 at 3:53 AM Ihor Radchenko <yantar92@gmail.com> wrote:

> "T.V Raman" <raman@google.com> writes:
>
> > 1. Accessibility as word used in isolation has now become mostly
> >    meaningless, to be concrete one has to ask "Accessibility to whom"?
> >
> > 2. So in the following, everything I say is with respect to users with
> >    visual impairments.
>
> This is exactly the perspective I was hoping to hear from you. Though
> this thread is not dedicated to visual impairments. (I guess you also
> did not touch the question of color blindness).
>
> > 3. It's incorrect to define "Accessibility" in terms of a specific
> >    user access tool or technology -- that usage is marketing jargon
> >    for a specific Access Solution like a screenreader --- so I refrain
> in general from
> >    defining this in terms of Screenreaders.
>
> Yet, in order to simplify the efforts needed to read a document exported
> from Org mode one needs to use some kind of tool/technology. Unless a
> common standard exist in this area, we have to support at least the most
> common Access Solutions (prioritizing Free software, if possible).
>
> From you message, it does not look like there is any common standard.
>
> > With those meta-thoughts out of the way:
> >
> > A: Org-generated documents are mostly well-structured documents, and ...
> > B: The LaTeX->PDF pipeline *can* produce tagged PDF with respect to ...
> > C: pdftex and pdflatex were built in the late 90's by a student in ...
> > D: All that said, it is likely still easier to go from org->HTML ...
>
> Do I understand correctly that you have no issues with reading documents
> exported using current version of Org?
>
> > E: Finally, note that in (D) I said "machine processable" not
> > "Accessible"; machine-processable is a pre-requisite to "repurpose "
> > what you publish, and making  that result usable by different user
> > communities is a direct consequence of suche machine-processability.
>
> I understand. But one can similarly say that .org files are "machine
> processable" and Org export code is not strictly necessary. Yet, it ends
> up extremely useful in practice.
>
> I suspect that the exported documents can similarly be improved to
> reduce the amount of efforts required from visually impair users to read
> such documents. The question is what kinds improvements can be made on
> Org side.
>
> Best,
> Ihor
>
>

[-- Attachment #2: Type: text/html, Size: 6907 bytes --]